Re: ATTACH with RSAPF=YES

[Clem Clarke]

I am afraid I have not been able to follow the whole conversation.  
However, it seems that perhaps attaching as a job step may be an answer?


This is the way the Initiator attaches a program.  The Initiator is 
authorised, and uses a special attach which will either attach a program 
in Problem State, or allow it to keep it's authorised state, if it is 
being loaded from an authorised library, and is linked with the 
appropriate option.


This code has been used for 40 years in my enhanced JCL language Jol, 
from which I created a program that allows parameters to be passed up to 
3,000 bytes.  The program is called LONGPARM and is CBT file number 839.


The enhanced JCL Language can be seen at www.Oscar-Jol.com

Here is the part of the code that shows how the Job Step option can be used.

--
***
*
*
*
* NOW ATTACH PROBLEM PROGRAM. 75311
*
* Note:  We could set up the SCT so that SMF records the "correct"
*program.  Wait for user feedback.
*
*
ATTACH   LAR1,#PARMPP  Get Address of User Parameters
 LHR15,#PARMPP Put some blanks at the end
 LAR15,2(R1,R15)   Point to end of string
 MVC 0(20,R15),BLANKS
 STR1,ATASKPRM Store it
 OIATASKPRM,X'80'  Set Hi Bit 75311
 LAR1,ATASKPRM Set R1 for Attach 75311
 XCTASKECB,TASKECB CLEAR ECB 75311
 MVC   ATTACHL(ATTACHLN),ATTACHW INITIALISE ATTACH
*  BECAUSE 'E' FORM DOESN'T INITIALISE
*  ALL THE BITS.
 ATTACH EPLOC=TASKNAME,ECB=TASKECB,SF=(E,ATTACHL), *
RSAPF=YES,  *
   JSTCB=YES,MF=(E,(1)) 76200
 LR R5,R1
 WAIT ECB=TASKECB
 MVC   TASKRETN(1),X'1D'(R5) SHIFT IN ABEND CODE
 MVC   TASKRETN+1(3),TASKECB+1 AND RETURN CODE
* NOW I'M BACK IN CONTROL,I.E THE SUBTASK FINISHED.
*WHAT AM I TO DO NOW ?
 ST R5,CALLAREA
 DETACH CALLAREA
TABEND   TMTASKRETN,128NORMAL RETURN FOR TASK? 75003
 BNO   TESTGOBK   YES,SO TEST GOBACK TO OS INDIC 76200
 ICR7,TASKRETN SET R7 = ABEND CODE
 L R1,TASKRETN LOAD TASKRETN TO REG 1
 ABEND (1)
*N R1,=X'00FF' LEAVE RETURN CODE
TESTGOBK EQU *
   SPACE 3
RETNOS   EQU *
 LHR10,TASKRETN+2  LOAD 2ND 2 BYTES OF RETURN CODE
BADRETN  EQU *
 L R7,4(R13)   LOAD R7 WITH PREVIOUS SAVEAREA ADDRESS
 LRR1,R13  LOAD R1 WITH THE ADDRESS OF GOTTEN
* STORAGE
 FREEMAIN R,LV=CONEND-CONSTART,A=(1)
 LRR13,R7  SET R13=OLD SAVE
 LRR15,R10 SET UP RETURN CODE
 L R14,12(13)  AND RETURN ADDRESS
 LMR0,R12,20(R13)  AND OLD REGISTERS
 BRR14 AND BACK WE GO
*
--


Clem Clarke


Robin Atwood wrote:

Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized.  If that is not the case, we might as well end the discussion
because there is no way to do that while maintaining system integrity, and
it is unlikely anyone would accept such a "solution".

Walt Farrell has pointed out approaches that are conceivably OK.

ATTACH with RSAPF=YES should be off the table.

Peter Relson
z/OS Core Technology Design


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

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



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

Re: you can request improvements to IBM Knowledge Center using the RFE process now

[Timothy Sipples]

Allan Staller wrote:
>The RAS for the support systems needs to be as least on the same
>order of magnitude as the systems they are supporting.

That'd be lovely, but unfortunately it's not possible. The public Internet,
and your particular connection to it, simply doesn't offer that assurance.

Fortunately the IBM Knowledge Center is a base z/OS operating system
feature. Please take advantage of it.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

ESTAE no SDWA ?

[Paul Schuster]

So when an SDWA is present in an ESTAE recovery routine, you
can do a SETRP REMREC=YES to have the ESTAE removed when you
do the retry.

When no SDWA is present, you cannot do the SETRP, so am I correct
in believing that the retry point must then do the ESTAE(X) 0 to
remove the ESTAE?

Thank you.

Paul

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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Edward Gould]

> On May 23, 2017, at 6:41 PM, Steve Beaver  wrote:
> 
> As we all know IBM has started the no more Remote work.  Looks like lots of
> folks in marketing said thanks but no thanks
> 
> Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
> that the U.S. marketing division's 2,600 employees would have to "co-locate"
> or collaborate onsite from one of six cities. Those who worked primarily
> from home would have to move to one of the cities or quit IBM.
> 
> For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
> workers worldwide telecommuted. As a result, it saved about $100 million a
> year in the U.S. and had reduced office space by 78 million square feet.
> 
> IBM remote workers who choose to resign rather than move to one of the six
> cities will be paid severance, according to an IBM internal document, of one
> month's base salary, the standard at IBM. Peluso says she plans to recruit
> replacements for those employees from the six co-located locations-not
> abroad. "If what I were trying to do was reduce headcount," she says, "there
> are much simpler and easier ways to do that, which would be less disruptive
> for everyone, myself included.”

> Can’t speak for other cities but in Chicago, There is/was a building that 
> housed mostly IBMers for at least 30 years that I remember. The address was 1 
> IBM Plaza.
It used to house IBM education/marketing and a data center (we IPLed the first 
version of MVS there late one night (or was it morning?)) I spent many weeks 
there in various IBM classes over the years.
A couple of years ago I went past the place and it looked deserted (and 
somewhat dirty).
I had a few friends that worked for IBM over the years and they moved to the 
East Coast and West Coast. 
I keep in touch a little with one now EX IBMer he was in G-burg and then the 
west coast.
I was extremely disappointed with IBM over the last say 20+ years. What was 
once excellent Marketing people were reduced to call centers and it showed to 
the customer.
We were an excellent customer of IBM and ordered the latest equipment available 
and really got over the top engineering support and marketing support. IBM once 
in a while would bring customers through our data center to show off any new 
equipment.
When we had major issues with IBM equipment the place was overrun with IBM 
types helping out and making good suggestions. One time our brand new 168MP 
wasn’t quite dead on delivery but close to. IBM showed that they supported the 
customer when a jet flew in from the east coast with about 20 IBM types. They 
problem was found a part was supplied that fixed the issue (too long of a tri 
lead wire going into the High speed buffer). Talk about unreproducible S0C4’s.

Then IBM started to go down little by little not as good support as they used 
to have. People seemed to be leaving IBM faster than they could hire. They 
tried to sell me a remote education class and I balked a little. I finally got 
them to not charge the company if I found it was unsatisfactory. The second day 
of the class I walked out and went to the person in charge  and told them to 
refund the money and to make sure they specified in the education catalog if it 
was remotely taught. I stayed away from all remotely taught classes. 

Then somewhere around 1995 I found I needed to ask a person who has had 
experience with encryption and key handling. (this was a 1-800 number) I was 
told I was going to have to pay IBM to get an answer about their product, I 
answered back I guess you don’t want to sell new hardware anymore and I hung up)
Then a few years laterI had some questions about hardware and was told the same 
thing.
I only called IBM when we had a service contract. Even the IBM software (parts 
of it anyway) broke every IBM rules there was. That was enough for me.
Good bye IBM it was nice for a while, not so much anymore.

Ed

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

Re: you can request improvements to IBM Knowledge Center using the RFE process now

[Anthony Thompson]

KC can be installed locally, with reduced functionality, as of z/OS 2.2. You 
don't have to depend on IBM servers.

I've said it before, and I'll say it again. The BIG advantage to KC is that it 
is web-searchable, unlike the majority of third-party mainframe (and other 
platforms) software products' documentation.

And having said that, I vastly prefer PDF's. Much easier to scroll through.

Ant.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, 23 May 2017 10:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: you can request improvements to IBM Knowledge Center using the RFE 
process now

On Tue, May 23, 2017 at 7:49 AM, Allan Staller 
wrote:

> Actually, KC seems to be one of the better of the "new tools".
>
> However, the new tools are neither as reliable, functional, nor 
> (especially)available as the tools they are replacing.
>
> Once IBM get out of the mindset that "It's OK to take down the support 
> portal for 24 hours, during the prime customer outage window" I might 
> back off on this stance.
>
> The RAS for the support systems needs to be as least on the same order 
> of magnitude as the systems they are supporting.
> The tools and mechanisms to provide this RAS are available, certainly 
> on *IX and (possibly) Windoze.
> IBM needs to exploit the mechanisms.
>

​Or as with what happened to me yesterday. I'm reading something. I click on 
the arrow to go to the next page. The site gets an 503 (Server
Unavailable) for I don't know how long. Longer than my cursing out IBM and KC. 
And, no I cannot download the entire KC for all the products I need. I don't 
have a big enough local drive and the SAN people send dunning emails if your 
personal share takes up "too much space" for "unnecessary" (in their opinion) 
files.​


--
Windows. A funny name for a operating system that doesn't let you see anything.

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: Hitachi to Deliver New Mainframe Based on IBM z Systems in Japan

[Timothy Sipples]

VOS3 is a fork of MVS. It mostly forked around the time of MVS/SP, although
later on it picked up many MVS/XA and MVS/ESA capabilities. Hitachi
implemented some basic 64-bit addressing support in VOS3 in the 2000s, as I
understand it (with VOS3/LS), although there isn't too much software that
exploits VOS3/LS's 64-bit features. (I think this 64-bit support is a
functional subset of z/Architecture as it was implemented in the z900,
although that subset is implemented somewhat differently.) The formal, long
name of the latest VOS3 releases is called VOS3/US.

IBM and Hitachi had a more narrow partnership agreement in the early 2000s.
Hitachi and IBM worked together on the IBM z800 machine, also sold in Japan
as a Hitachi VOS3 machine (and also supporting Hitachi's unique 64-bit
architecture). IBM provided the processors and some other components, and
Hitachi designed and built the machine itself. The z800's successor, the
IBM z890 machine, built by IBM, also officially supported VOS3 in Japan, if
my recollection is correct. (And possibly the z9BC did as well, although
I'm less sure about that. At some point, as the IBM machines evolved, they
lost official Hitachi support and the technical tweak to run VOS3.) That
early 2000s partnership never extended to the higher capacity machines
(z900, z990, etc.) as I recall. (Even so, especially for their era, these
partnership machines were big enough for most VOS3 customers.) The new
partnership, announced on May 23, 2017, applies to all IBM z System
machines, to address all VOS3 customer capacity needs.

To net it out, Hitachi VOS3 joins (or rejoins) the list of vendor supported
operating systems on this family of machines, now across the full range of
machines. Hitachi's Japanese version of the announcement indicates that
formal product introductions in Japan will occur in Fiscal Year 2018.
FY2018 starts on April 1, 2018. That could be less than a year from
announcement of this partnership, in other words. Hitachi and IBM have
agreed that z System machines will be the successors to the Hitachi AP
series machines.

I'm very happy Hitachi and IBM have established this partnership and are
working closely together. It's especially great news for VOS3 customers.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Edward Finnell]

RFID's? Who was it Watson, Sr. wanted to have everyone tattooed for census  
purposes? Was not well received.
 
In a message dated 5/23/2017 7:58:40 P.M. Central Daylight Time,  
stars...@mindspring.com writes:

So if  there are six co-located locations, how is one Manager supposed to 
over see  everyone in their chair if the manager  is in City A but employee 
is in  City B.


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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Lizette Koehler]

So if there are six co-located locations, how is one Manager supposed to over 
see everyone in their chair if the manager  is in City A but employee is in 
City B.

Does not make sense.  Especially if they saved 100 Million by having these 
workers remote to start with.


Crazy

Lizette

-Original Message-
>From: Doug Fuerst 
>Sent: May 23, 2017 4:58 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Looks like lots of folks in marketing said thanks but no thanks
>
>  I wonder if or when they will give this one and Ginny Rometty their 
>walking papers. IBM has been faltering for years. Maybe a change in the 
>senior ranks would be in order.
>
>Doug Fuerst
>
>
>
>-- Original Message --
>From: "Steve Beaver" 
>To: IBM-MAIN@listserv.ua.edu
>Sent: 23-May-17 7:41:00 PM
>Subject: Looks like lots of folks in marketing said thanks but no thanks
>
>>As we all know IBM has started the no more Remote work. Looks like lots 
>>of
>>folks in marketing said thanks but no thanks
>>
>>Earlier this year, IBM's Chief Marketing Officer Michelle Peluso 
>>announced
>>that the U.S. marketing division's 2,600 employees would have to 
>>"co-locate"
>>or collaborate onsite from one of six cities. Those who worked 
>>primarily
>>from home would have to move to one of the cities or quit IBM.
>>
>>For decades, IBM embraced remote work. Eight years ago, 40 percent of 
>>IBM
>>workers worldwide telecommuted. As a result, it saved about $100 
>>million a
>>year in the U.S. and had reduced office space by 78 million square 
>>feet.
>>
>>IBM remote workers who choose to resign rather than move to one of the 
>>six
>>cities will be paid severance, according to an IBM internal document, 
>>of one
>>month's base salary, the standard at IBM. Peluso says she plans to 
>>recruit
>>replacements for those employees from the six co-located locations-not
>>abroad. "If what I were trying to do was reduce headcount," she says, 
>>"there
>>are much simpler and easier ways to do that, which would be less 
>>disruptive
>>for everyone, myself included."
>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: Looks like lots of folks in marketing said thanks but no thanks

[Steve Beaver]

IBM will never say for a while 

Sent from my iPhone

Sorry for any grammar problems 

> On May 23, 2017, at 19:51, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Tue, 23 May 2017 18:41:00 -0500, Steve Beaver wrote:
>> 
>> As we all know IBM has started the no more Remote work.  Looks like lots of
>> folks in marketing said thanks but no thanks
>> 
> "Lots"?  I see no numbers.  Citation needed?
> 
>> Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
>> that the U.S. marketing division's 2,600 employees would have to "co-locate"
>> or collaborate onsite from one of six cities. Those who worked primarily
>> from home would have to move to one of the cities or quit IBM.
>> 
>> For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
>> workers worldwide telecommuted. As a result, it saved about $100 million a
>> year in the U.S. and had reduced office space by 78 million square feet.
>> 
>> IBM remote workers who choose to resign rather than move to one of the six
>> cities will be paid severance, according to an IBM internal document, of one
>> month's base salary, the standard at IBM. Peluso says she plans to recruit
>> replacements for those employees from the six co-located locations-not
>> abroad. "If what I were trying to do was reduce headcount," she says, "there
>> are much simpler and easier ways to do that, which would be less disruptive
>> for everyone, myself included."
> 
> -- 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: Looks like lots of folks in marketing said thanks but no thanks

[Paul Gilmartin]

On Tue, 23 May 2017 18:41:00 -0500, Steve Beaver wrote:

>As we all know IBM has started the no more Remote work.  Looks like lots of
>folks in marketing said thanks but no thanks
> 
"Lots"?  I see no numbers.  Citation needed?

>Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
>that the U.S. marketing division's 2,600 employees would have to "co-locate"
>or collaborate onsite from one of six cities. Those who worked primarily
>from home would have to move to one of the cities or quit IBM.
>
>For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
>workers worldwide telecommuted. As a result, it saved about $100 million a
>year in the U.S. and had reduced office space by 78 million square feet.
>
>IBM remote workers who choose to resign rather than move to one of the six
>cities will be paid severance, according to an IBM internal document, of one
>month's base salary, the standard at IBM. Peluso says she plans to recruit
>replacements for those employees from the six co-located locations-not
>abroad. "If what I were trying to do was reduce headcount," she says, "there
>are much simpler and easier ways to do that, which would be less disruptive
>for everyone, myself included."

-- gil

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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Steve Beaver]

Every organization in the world needs a good house-cleaning and god knows
the Federal Government needs a major cleaning.  However in the scheme of
things 2,600 people are not many out of 380,000.  And probably most of them
are going to IBM's retired payroll.

As Peter said they may not be selling much, however the patent royalties are
astronomiocal
 
Steve 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, May 23, 2017 7:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looks like lots of folks in marketing said thanks but no thanks

Classic Type-A uptight managerial style.  "If I can't see you then you must
not be working, because I wouldn't be!"

Sheesh.  When will they learn to judge people by what they accomplish rather
than how often they are seen.

Then again, these are "marketing" (i.e., sales) employees.  Given how much
less IBM seems to be selling, maybe the housecleaning could be good for IBM.

My sympathies are still with the workers though.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, May 23, 2017 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looks like lots of folks in marketing said thanks but no thanks

As we all know IBM has started the no more Remote work.  Looks like lots of
folks in marketing said thanks but no thanks

Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
that the U.S. marketing division's 2,600 employees would have to "co-locate"
or collaborate onsite from one of six cities. Those who worked primarily
from home would have to move to one of the cities or quit IBM.

For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
workers worldwide telecommuted. As a result, it saved about $100 million a
year in the U.S. and had reduced office space by 78 million square feet.

IBM remote workers who choose to resign rather than move to one of the six
cities will be paid severance, according to an IBM internal document, of one
month's base salary, the standard at IBM. Peluso says she plans to recruit
replacements for those employees from the six co-located locations-not
abroad. "If what I were trying to do was reduce headcount," she says, "there
are much simpler and easier ways to do that, which would be less disruptive
for everyone, myself included."

--

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

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

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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Farley, Peter x23353]

Classic Type-A uptight managerial style.  "If I can't see you then you must not 
be working, because I wouldn't be!"

Sheesh.  When will they learn to judge people by what they accomplish rather 
than how often they are seen.

Then again, these are "marketing" (i.e., sales) employees.  Given how much less 
IBM seems to be selling, maybe the housecleaning could be good for IBM.

My sympathies are still with the workers though.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Tuesday, May 23, 2017 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looks like lots of folks in marketing said thanks but no thanks

As we all know IBM has started the no more Remote work.  Looks like lots of
folks in marketing said thanks but no thanks

Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
that the U.S. marketing division's 2,600 employees would have to "co-locate"
or collaborate onsite from one of six cities. Those who worked primarily
from home would have to move to one of the cities or quit IBM.

For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
workers worldwide telecommuted. As a result, it saved about $100 million a
year in the U.S. and had reduced office space by 78 million square feet.

IBM remote workers who choose to resign rather than move to one of the six
cities will be paid severance, according to an IBM internal document, of one
month's base salary, the standard at IBM. Peluso says she plans to recruit
replacements for those employees from the six co-located locations-not
abroad. "If what I were trying to do was reduce headcount," she says, "there
are much simpler and easier ways to do that, which would be less disruptive
for everyone, myself included."

--

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: Looks like lots of folks in marketing said thanks but no thanks

[Charles Mills]

Crazy. Just crazy.

Memo to IBM: Telecommuting is the future.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Tuesday, May 23, 2017 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looks like lots of folks in marketing said thanks but no thanks

As we all know IBM has started the no more Remote work.  Looks like lots of
folks in marketing said thanks but no thanks

Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
that the U.S. marketing division's 2,600 employees would have to "co-locate"
or collaborate onsite from one of six cities. Those who worked primarily
from home would have to move to one of the cities or quit IBM.

For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
workers worldwide telecommuted. As a result, it saved about $100 million a
year in the U.S. and had reduced office space by 78 million square feet.

IBM remote workers who choose to resign rather than move to one of the six
cities will be paid severance, according to an IBM internal document, of one
month's base salary, the standard at IBM. Peluso says she plans to recruit
replacements for those employees from the six co-located locations-not
abroad. "If what I were trying to do was reduce headcount," she says, "there
are much simpler and easier ways to do that, which would be less disruptive
for everyone, myself included."

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

Re: Looks like lots of folks in marketing said thanks but no thanks

[Doug Fuerst]

 I wonder if or when they will give this one and Ginny Rometty their 
walking papers. IBM has been faltering for years. Maybe a change in the 
senior ranks would be in order.


Doug Fuerst



-- Original Message --
From: "Steve Beaver" 
To: IBM-MAIN@listserv.ua.edu
Sent: 23-May-17 7:41:00 PM
Subject: Looks like lots of folks in marketing said thanks but no thanks

As we all know IBM has started the no more Remote work. Looks like lots 
of

folks in marketing said thanks but no thanks

Earlier this year, IBM's Chief Marketing Officer Michelle Peluso 
announced
that the U.S. marketing division's 2,600 employees would have to 
"co-locate"
or collaborate onsite from one of six cities. Those who worked 
primarily

from home would have to move to one of the cities or quit IBM.

For decades, IBM embraced remote work. Eight years ago, 40 percent of 
IBM
workers worldwide telecommuted. As a result, it saved about $100 
million a
year in the U.S. and had reduced office space by 78 million square 
feet.


IBM remote workers who choose to resign rather than move to one of the 
six
cities will be paid severance, according to an IBM internal document, 
of one
month's base salary, the standard at IBM. Peluso says she plans to 
recruit

replacements for those employees from the six co-located locations-not
abroad. "If what I were trying to do was reduce headcount," she says, 
"there
are much simpler and easier ways to do that, which would be less 
disruptive

for everyone, myself included."

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

Looks like lots of folks in marketing said thanks but no thanks

[Steve Beaver]

As we all know IBM has started the no more Remote work.  Looks like lots of
folks in marketing said thanks but no thanks

Earlier this year, IBM's Chief Marketing Officer Michelle Peluso announced
that the U.S. marketing division's 2,600 employees would have to "co-locate"
or collaborate onsite from one of six cities. Those who worked primarily
from home would have to move to one of the cities or quit IBM.

For decades, IBM embraced remote work. Eight years ago, 40 percent of IBM
workers worldwide telecommuted. As a result, it saved about $100 million a
year in the U.S. and had reduced office space by 78 million square feet.

IBM remote workers who choose to resign rather than move to one of the six
cities will be paid severance, according to an IBM internal document, of one
month's base salary, the standard at IBM. Peluso says she plans to recruit
replacements for those employees from the six co-located locations-not
abroad. "If what I were trying to do was reduce headcount," she says, "there
are much simpler and easier ways to do that, which would be less disruptive
for everyone, myself included."

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

Re: SMFRTEST with SUBTYPE

[Charles Mills]

Oh h3ll, never mind. Nothing like posting on IBM-MAIN to help you find your
error.

Charles


-Original Message-
From: Charles Mills [mailto:charl...@mcn.org] 
Sent: Tuesday, May 23, 2017 3:17 PM
To: IBM Mainframe Discussion List (IBM-MAIN@listserv.ua.edu)
Subject: SMFRTEST with SUBTYPE

I've been using SMFRTEST without a SUBTYPE specification for some time. I
get the expected results for RECTYPE=x if SMF record type x is not being
recorded for a given subsystem.

I just coded it with a SUBTYPE specification for the first time and was
surprised to see that apparently if RECTYPE=x is not being recorded at all
for a given subsystem then RECTYPE=x,SUBTYPE=y seems to return 00 -- the
record type is being recorded.

Is this the behavior others have seen or should I suspect a coding problem
on my part? I've desk-checked the code pretty thoroughly.

Charles 

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

SMFRTEST with SUBTYPE

[Charles Mills]

I've been using SMFRTEST without a SUBTYPE specification for some time. I
get the expected results for RECTYPE=x if SMF record type x is not being
recorded for a given subsystem.

I just coded it with a SUBTYPE specification for the first time and was
surprised to see that apparently if RECTYPE=x is not being recorded at all
for a given subsystem then RECTYPE=x,SUBTYPE=y seems to return 00 -- the
record type is being recorded.

Is this the behavior others have seen or should I suspect a coding problem
on my part? I've desk-checked the code pretty thoroughly.

Charles 

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

Re: SDB (system determined Blksize)

[Jesse 1 Robinson]

If I understand the details: 

First copy operation read a whole bunch of smallish blocks and wrote out SDB 
blocks at 2/track. Lots of overhead on reads, much less so on writes. I would 
expect this result. 

Second copy operation both read and wrote SDB blocks, so minimal overhead on 
both sides. I would expect this result.

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, May 23, 2017 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SDB (system determined Blksize)

About a dozen copies at 1/2 track block size vs `1 copy from small block size 
to 1/2 track in the same elapsed time.

On Tue, May 23, 2017 at 8:14 AM, Charles Mills  wrote:
>> The subsequent several copies ran much faster and also took about 10 minutes.
>
> But it was a much faster 10 minutes?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mike Schwab
> Sent: Monday, May 22, 2017 10:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SDB (system determined Blksize)
>
> Every time you deal with a block you execute a bit of code to deblock the 
> records.  To fill a Mod 9 volumes to test TDMF I copied a large dataset with 
> a small block size to a dataset with half track blocking on a spare volume, 
> then copied the first data set to several other datasets to fill the volume.  
> The first copy to the half track blocksize took about 10 minutes.  The 
> subsequent several copies ran much faster and also took about 10 minutes.
>
> --
> 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: SDB (system determined Blksize)

[Mike Schwab]

About a dozen copies at 1/2 track block size vs `1 copy from small
block size to 1/2 track in the same elapsed time.

On Tue, May 23, 2017 at 8:14 AM, Charles Mills  wrote:
>> The subsequent several copies ran much faster and also took about 10 minutes.
>
> But it was a much faster 10 minutes?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Schwab
> Sent: Monday, May 22, 2017 10:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SDB (system determined Blksize)
>
> Every time you deal with a block you execute a bit of code to deblock the 
> records.  To fill a Mod 9 volumes to test TDMF I copied a large dataset with 
> a small block size to a dataset with half track blocking on a spare volume, 
> then copied the first data set to several other datasets to fill the volume.  
> The first copy to the half track blocksize took about 10 minutes.  The 
> subsequent several copies ran much faster and also took about 10 minutes.
>
> --
> 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: RACF Database

[Jesse 1 Robinson]

So it turns out that the number of folks here with ALTER access to RACF data 
sets is way smaller than I expected. There are however several userids with 
UPDATE access; they seem to be mostly in the 'security management' department. 
Do the standard RACF utilities require UPDATE for housekeeping? 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Tuesday, May 23, 2017 12:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database

It should go without saying that ALTER (and even READ) access to the RACF 
database data set should be restricted to those that really need direct access 
to the database data set itself.  Ordinary users and even RACF administrators 
should have NONE access to the RACF database data set.  I would have been one 
with ALTER authority. 

I always preferred, whenever not too difficult, to put in place additional 
barriers that would require a positive, deliberate act before a single mistake 
could cause a disastrous consequence, not just assume that those with the 
authority to create a disaster will never commit an error -- like submitting a 
defrag for a drive and then realizing by harsh empirical evidence it had a 
critical active data set like a RACF database that lacked an enqueue.  In our 
case, decades ago, it was an automated system job that ran in the middle of the 
night that conditionally decided what drives to defrag based on fragmentation 
index.  Ran for months without incident until the night the fragmentation index 
threshold was reached on the drive with the RACF database, and the console 
filled up with red RACF I/O failures!  Didn't take long to deduce what had 
happened -- we had to restore the database using our one-drive MVS system, and 
took steps to reduce odds it could ever happen again.
 Joel C. Ewing

On 05/23/2017 01:36 PM, Burrell, Todd wrote:
> Wouldn't a simpler solution to protecting the RACF database simply be to give 
> pretty much no one ALTER access to it?   I know that at most shops only one 
> or two folks had ALTER or UPDATE to the actual file and that seems like the 
> best course of action to avoid accidental deletion? 
> And we backed up the RACF DB 4 times a day as well - just in case.  
>
> Todd Burrell | Sr. Mainframe Systems Administrator
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using 
> NJE/TCPIP)
>
> I have not tried this, but IBM supplies a RACF started task whose purpose is 
> to issue RACF commands via a console. As supplied, the RACF STC has no DDs, 
> but I suppose you could add one for the primary and maybe even alternate RACF 
> data base(s) with DISP=SHR. The hard part of coding such a task has already 
> been done. Stopping it seems to require FORCE ARM, but you wouldn't stop it 
> very often anyway. 
>
> -
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 11:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file 
> transfer using NJE/TCPIP)
>
> I've been expecting someone with actual experience in this area to jump in. I 
> don't think you can get away with 'wait forever' logic. Eventually you'll get 
> S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
> libraries, seems to be very busy doing something, accumulating both CPU time 
> and EXCP count. Maybe there's something on CBT?
>
> 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Monday, May 22, 2017 4:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file 
> transfer using NJE/TCPIP)
>
> On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:
>
>> RECFM PSU may prevent moving the database, but it doesn't block 
>> deletion.  After realizing this somewhat-essential data set wasn't 
>> protected by an enqueue, we picked an installation started task that 
>> was normally running all the time (but which could be shut down if 
>> need be), and added an unreferenced DD for the RACF database with 
>> DISP=SHR to reduce the odds of both accidental deletion and movement.
>>
> Suppose one wanted to craft 

Re: Hitachi to Deliver New Mainframe Based on IBM z Systems in Japan

[Charles Mills]

Some here surely knows: how compatible is Hitachi VOS3 with z/OS? Is it a 
superset of some version of OS/390 or z/OS?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Jones
Sent: Tuesday, May 23, 2017 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Hitachi to Deliver New Mainframe Based on IBM z Systems in Japan

https://finance.yahoo.com/news/hitachi-deliver-mainframe-based-ibm-14183.html?__prclt=iOFCjait

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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

Someone else pointed out that xxxSTOP works for the RACF STC, where xxx is the 
subsystem identifier specified in IEFSSNxx. 

In a larger shop, severely limiting access to *any* resource is problematic. If 
the installation needs 24x7 support, someone has to hold the key, and that 
someone has to be available to put it in the lock. I agree that too much access 
is a dangerous thing, but too little can be crippling as well. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Tuesday, May 23, 2017 12:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is 
@STOP). It also can be started again as well. The only cost is "address space 
unavailable" issue.

Of course *properly protected* RACF db cannot be moved or deleted, due to lack 
of authorities. No one should have even READ to this profile.

BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM 
access method? Who cares!

R.Skorupka 
(sent from mobile)


BTW


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

Re: SLIP with ACTION=NOSUP

[Lizette Koehler]

So NOSUP will probably not do what you want.

Have you looked at the LE options

Derivation: DYNamic DUMP

The DYNDUMP runtime option provides a way to obtain dynamic dumps of user 
applications that would ordinarily be lost due to the absence of a SYSMDUMP, 
SYSUDUMP, or SYSABEND DD statement. The dynamic dump is written when:

Certain types of ABENDs occur. You can select if a U4039 ABEND or other 
U40xx ABEND types can cause a dump to be collected.
The first suboption defines the high level qualifier of the dynamic dump 
data set name.
The second suboption controls when dynamic dumps are taken for U4039 ABENDS.
The third suboption controls when dynamic dumps are taken for other U40xx 
ABENDS.

Restriction: The dump is written to a z/OS® data set. It cannot be part of a 
z/OS UNIX file system.

The non-CICS default value is DYNDUMP(*userid,NODYNAMIC,TDUMP).

DYNDUMP is ignored under CICS®.

The AMODE 64 default value is DYNDUMP(*userid,NODYNAMIC,TDUMP).


Lizette



-Original Message-
>From: Peter Hunkeler 
>Sent: May 23, 2017 12:39 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: SLIP with ACTION=NOSUP
>
>LE runtime option TERMTHDACT allows to ask for a system dump to be taken when 
>a problem occurs. LE then ABENDs the application with a U4039 when a problem 
>occurs.
>
>
>I like to have this dump be written to SYSMDUMP, so I can analyze with IPCS. 
>Unfortunately, DAE suppresses those dumps, because they are all requested by 
>the same LE runtime module, and the symptom string is always the same.
>
>I thought I could have my sysprog set a SLIP COMP=U4039,A=NOSUP to ask DAE not 
>to suppress those SYSMDUMPs.
>
>However, when I tried the next abend after the SLIP was set, I received 
>"IEA848I NO DUMP WAS PRODUCED FOR THIS ABEND, DUE TO SYSTEM OR INSTALLATION 
>REQUEST".
>
>I was able to take a first SYSMDUMP *before* the SLIP, since DAE did not have 
>a recent symptom string for such a U4039. For second run of the job, I was 
>told DAE had suppressed the dump as duplicate. This is why the IEA848I 
>astonished me.
>
>The SLIP above does not seem to what I need? What am I missing?
>
>--
>Peter Hunkeler
>
>

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

Hitachi to Deliver New Mainframe Based on IBM z Systems in Japan

[Dave Jones]

https://finance.yahoo.com/news/hitachi-deliver-mainframe-based-ibm-14183.html?__prclt=iOFCjait

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

SLIP with ACTION=NOSUP

[Peter Hunkeler]

LE runtime option TERMTHDACT allows to ask for a system dump to be taken when a 
problem occurs. LE then ABENDs the application with a U4039 when a problem 
occurs.


I like to have this dump be written to SYSMDUMP, so I can analyze with IPCS. 
Unfortunately, DAE suppresses those dumps, because they are all requested by 
the same LE runtime module, and the symptom string is always the same.


I thought I could have my sysprog set a SLIP COMP=U4039,A=NOSUP to ask DAE not 
to suppress those SYSMDUMPs.


However, when I tried the next abend after the SLIP was set, I received 
"IEA848I NO DUMP WAS PRODUCED FOR THIS ABEND, DUE TO SYSTEM OR INSTALLATION 
REQUEST".


I was able to take a first SYSMDUMP *before* the SLIP, since DAE did not have a 
recent symptom string for such a U4039. For second run of the job, I was told 
DAE had suppressed the dump as duplicate. This is why the IEA848I astonished me.



The SLIP above does not seem to what I need? What am I missing?




--
Peter Hunkeler


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

Re: RACF Database

[Joel C. Ewing]

It should go without saying that ALTER (and even READ) access to the
RACF database data set should be restricted to those that really need
direct access to the database data set itself.  Ordinary users and even
RACF administrators should have NONE access to the RACF database data
set.  I would have been one with ALTER authority. 

I always preferred, whenever not too difficult, to put in place
additional barriers that would require a positive, deliberate act before
a single mistake could cause a disastrous consequence, not just assume
that those with the authority to create a disaster will never commit an
error -- like submitting a defrag for a drive and then realizing by
harsh empirical evidence it had a critical active data set like a RACF
database that lacked an enqueue.  In our case, decades ago, it was an
automated system job that ran in the middle of the night that
conditionally decided what drives to defrag based on fragmentation
index.  Ran for months without incident until the night the
fragmentation index threshold was reached on the drive with the RACF
database, and the console filled up with red RACF I/O failures!  Didn't
take long to deduce what had happened -- we had to restore the database
using our one-drive MVS system, and took steps to reduce odds it could
ever happen again.
 Joel C. Ewing

On 05/23/2017 01:36 PM, Burrell, Todd wrote:
> Wouldn't a simpler solution to protecting the RACF database simply be to give 
> pretty much no one ALTER access to it?   I know that at most shops only one 
> or two folks had ALTER or UPDATE to the actual file and that seems like the 
> best course of action to avoid accidental deletion? 
> And we backed up the RACF DB 4 times a day as well - just in case.  
>
> Todd Burrell | Sr. Mainframe Systems Administrator 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
>
> I have not tried this, but IBM supplies a RACF started task whose purpose is 
> to issue RACF commands via a console. As supplied, the RACF STC has no DDs, 
> but I suppose you could add one for the primary and maybe even alternate RACF 
> data base(s) with DISP=SHR. The hard part of coding such a task has already 
> been done. Stopping it seems to require FORCE ARM, but you wouldn't stop it 
> very often anyway. 
>
> -
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, May 23, 2017 11:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file transfer 
> using NJE/TCPIP)
>
> I've been expecting someone with actual experience in this area to jump in. I 
> don't think you can get away with 'wait forever' logic. Eventually you'll get 
> S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
> libraries, seems to be very busy doing something, accumulating both CPU time 
> and EXCP count. Maybe there's something on CBT?
>
> 
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Monday, May 22, 2017 4:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RACF Database (was: Sample JCL for file transfer 
> using NJE/TCPIP)
>
> On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:
>
>> RECFM PSU may prevent moving the database, but it doesn't block 
>> deletion.  After realizing this somewhat-essential data set wasn't 
>> protected by an enqueue, we picked an installation started task that 
>> was normally running all the time (but which could be shut down if need 
>> be), and added an unreferenced DD for the RACF database with DISP=SHR 
>> to reduce the odds of both accidental deletion and movement.
>>
> Suppose one wanted to craft a started task expressly for that purpose, using 
> minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
> Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
> command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
> analogue of SIGINT?
>
> -- gil
>
>
> ...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Radoslaw Skorupka]

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is 
@STOP). It also can be started again as well. The only cost is "address space 
unavailable" issue.

Of course *properly protected* RACF db cannot be moved or deleted, due to lack 
of authorities. No one should have even READ to this profile.

BTW: VSAM dataset can be read very early - see IODF file. Is it pure VSAM 
access method? Who cares!

R.Skorupka 
(sent from mobile)


BTW

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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Burrell, Todd]

Wouldn't a simpler solution to protecting the RACF database simply be to give 
pretty much no one ALTER access to it?   I know that at most shops only one or 
two folks had ALTER or UPDATE to the actual file and that seems like the best 
course of action to avoid accidental deletion? 
And we backed up the RACF DB 4 times a day as well - just in case.  

Todd Burrell | Sr. Mainframe Systems Administrator 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

I have not tried this, but IBM supplies a RACF started task whose purpose is to 
issue RACF commands via a console. As supplied, the RACF STC has no DDs, but I 
suppose you could add one for the primary and maybe even alternate RACF data 
base(s) with DISP=SHR. The hard part of coding such a task has already been 
done. Stopping it seems to require FORCE ARM, but you wouldn't stop it very 
often anyway. 

-
.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.


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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

I have not tried this, but IBM supplies a RACF started task whose purpose is to 
issue RACF commands via a console. As supplied, the RACF STC has no DDs, but I 
suppose you could add one for the primary and maybe even alternate RACF data 
base(s) with DISP=SHR. The hard part of coding such a task has already been 
done. Stopping it seems to require FORCE ARM, but you wouldn't stop it very 
often anyway. 

-
.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Jesse 1 Robinson]

I've been expecting someone with actual experience in this area to jump in. I 
don't think you can get away with 'wait forever' logic. Eventually you'll get 
S522 abend. OTOH XCFAS, which preserves a permanent enqueue on LINKLIST 
libraries, seems to be very busy doing something, accumulating both CPU time 
and EXCP count. Maybe there's something on CBT?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 22, 2017 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote:

>RECFM PSU may prevent moving the database, but it doesn't block 
>deletion.  After realizing this somewhat-essential data set wasn't 
>protected by an enqueue, we picked an installation started task that 
>was normally running all the time (but which could be shut down if need 
>be), and added an unreferenced DD for the RACF database with DISP=SHR 
>to reduce the odds of both accidental deletion and movement.
>
Suppose one wanted to craft a started task expressly for that purpose, using 
minimum resource.  Would it suffice to WAIT on an ECB that you never POSTed?  
Would this annoy WLM?  Is there a better way?  Should it intercept a STOP 
command and WTOR with an Abort/Retry/Ignore prompt?  What's the OS Classic 
analogue of SIGINT?

-- gil


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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[David W Noon]

On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) 
wrote about "Re: RACF Database (was: Sample JCL for file transfer using 
NJE/TCPIP)" (in 

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Tony Harminc]

On 22 May 2017 at 12:57, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> > ... In any case, a SAF product has to be available extremely early in
> IPL, ...
> >
> How does ACF2, based on VSAM, meet this requirement of early availability?
>

The same way it would if ACF2 used BDAM or QSAM or... VSAM is not like VTAM
or TCP/IP or z/OS UNIX filesystems. There is no "VSAM address space" to be
initialized at some point in the IPL.*  VSAM is almost entirely a
collection of subroutines, just like the older access methods.

* These days there are all sorts of "helper" address spaces around - VLF,
LLA, CATALOG, ... and I suppose one of those may need to be active in order
to allocate and open a VSAM dataset. But just to do the I/O, I don't think
so.

Tony H.

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

Re: z/OS 2.3 preview announcement (mailto:)

[Paul Gilmartin]

On 2017-05-23, at 06:28, גדי בן אבי wrote:

> There is a new NOTIFY JCL statement.
> It will allow you to send the notification to up to 8 addresses.
>  
I trimmed a lot.  It also mentions that NOTIFY can be contingent on
step termination codes, etc.

But I wonder, couldn't there be more flexibility with a SENDMAIL
utility (EXEC PGM=SENDMAIL), a system-like symbol, ,
akin to , and use of IF/THEN/ELSE?

And a JCL function (a new concept) returning the termination code
of a step, which could be imbedded in DD *,SYMBOLS=... (syntactic
ambiguity could be resolved with a SET statement.

(JCL desperately needs HLASM's DEQUOTE and DOUBLE functions.)

(Why do IF relational expressions, referbacks, and overrides
not support unambiguous references to steps in nested procedure
calls (stepname.procstepname.subprocstepname. ...)!?)

And a JCL function returning the email address of its argument
userID.

Introduce new facilities with maximum orthogonality, but rely
on existing facilities where they suffice.

-- gil

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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Dana Mitchell]

On Tue, 23 May 2017 07:30:02 -0500, John McKown  
wrote:

>On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson 
>wrote:
>
>> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
>> the primary RACF data base. It was not enqueued on as previously noted.
>>
>
>​Been there. Done that. Beat up the programmer.
>

One also gets a similar pleasing effect if you run an IRRUT200 step with DD 
SYSUT1 pointing to the RACF Database.

Dana

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

Re: FYI: you can request improvements to IBM Knowledge Center using the RFE process now

[Kirk Wolf]

Is this a live load test for the RFE system? :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, May 23, 2017 at 7:27 AM, John Arwe 
wrote:

> I know KC is a "popular" topic here [ducks].
>
> Net net, you can now submit/vote/comment on KC enhancement requests on
> the web
>
> Direct link:
> https://www.ibm.com/developerworks/rfe/execute?
> use_case=changeRequestLanding_ID=0_ID=1672=17=14
>
>
> if the URL parameters change incompatibly some day, that's in
> the RFE community at https://www.ibm.com/developerworks/rfe/
>
> From the RFE community page, the simplest route I've found is to
> - click in the All Products drop-down and type "know"
>   (which is enough, as of today, to get you to KC...
>   over time, more characters might be required)
> - hit Enter to select IBM Knowledge Center
> - click on the icon to the right of the product drop-down
>   (looks like a bold-face greater-than sign)
>
> --- full text ---
> IBM Knowledge Center is now in the Request for Enhancement (RFE)
> Community, where external IBM product users can make suggestions for
> improving our IBM KC application and its content. Besides opening and
> tracking new requests, users can also search existing requests, and
> comment on them as well. The RFE Community provides a great opportunity
> for users to interact more directly with the IBM KC and product
> development teams. So we urge you to tell your customers about it
> through your interactions with them, through social media, and through
> your product documentation! Visit the RFE Community and check it out!
>
> Related RFE Community information
> Help - https://www.ibm.com/developerworks/rfe/execute?use_case=tutorials
> You can find the following topics on the Help tab.
> -Learn about the request process
> -Learn about how to submit, view and send out notifications on requests
> -How to search for requests
> -How to watch for and get notified on requests
> -How to use groups
> Note: You need an IBMid and password to use any feature other than Help.
>
>
> --- John Arwe, IBM
>
> --
> 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: ATTACH with RSAPF=YES

[Robin Atwood]

Thanks, John. I have constructed a bare-bones testbed in HLASM and called 
BPX1FRK and it "Just Worked". :) The
cool thing is the child process is created in a BPXAS address space that is 
just lying around and doesn't need to be 
created. And, according to the doc, in the real case where the STC is multi-TCB 
only the TCB issuing the fork gets cloned in the new ASID, exactly what I want. 

--
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 23 May 2017 19:41
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

On Tue, May 23, 2017 at 2:43 AM, Robin Atwood  wrote:

> Yes, the point was taken. I am now investigating using fork() to 
> spin-off another address space.
>

​From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how much you're "in to" what can be done, but there are some
nice(!) facilities that fork() can leverage.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm

You can use the C language setenv() to set a number of UNIX environment 
variables with can affect the results of fork() if you have the right RACF 
authorities set up.

_BPX_JOB NAME can set the name of the fork'd address space (such as to the 
user's name) _B PX_USERID can set the RACF owner for the fork'd address space. 
The address space doing the fork() needs some "heavy" RACF authorities for this.





>
> Thanks
> Robin
>
>

--
Windows. A funny name for a operating system that doesn't let you see anything.

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: SDB (system determined Blksize)

[Charles Mills]

> The subsequent several copies ran much faster and also took about 10 minutes.

But it was a much faster 10 minutes?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, May 22, 2017 10:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDB (system determined Blksize)

Every time you deal with a block you execute a bit of code to deblock the 
records.  To fill a Mod 9 volumes to test TDMF I copied a large dataset with a 
small block size to a dataset with half track blocking on a spare volume, then 
copied the first data set to several other datasets to fill the volume.  The 
first copy to the half track blocksize took about 10 minutes.  The subsequent 
several copies ran much faster and also took about 10 minutes.

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

Re: you can request improvements to IBM Knowledge Center using the RFE process now

[John McKown]

On Tue, May 23, 2017 at 7:49 AM, Allan Staller 
wrote:

> Actually, KC seems to be one of the better of the "new tools".
>
> However, the new tools are neither as reliable, functional, nor
> (especially)available as the tools they are replacing.
>
> Once IBM get out of the mindset that "It's OK to take down the support
> portal for 24 hours, during the prime customer outage window" I might back
> off on this stance.
>
> The RAS for the support systems needs to be as least on the same order of
> magnitude as the systems they are supporting.
> The tools and mechanisms to provide this RAS are available, certainly on
> *IX and (possibly) Windoze.
> IBM needs to exploit the mechanisms.
>

​Or as with what happened to me yesterday. I'm reading something. I click
on the arrow to go to the next page. The site gets an 503 (Server
Unavailable) for I don't know how long. Longer than my cursing out IBM and
KC. And, no I cannot download the entire KC for all the products I need. I
don't have a big enough local drive and the SAN people send dunning emails
if your personal share takes up "too much space" for "unnecessary" (in
their opinion) files.​


-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

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: you can request improvements to IBM Knowledge Center using the RFE process now

[Allan Staller]

Actually, KC seems to be one of the better of the "new tools".

However, the new tools are neither as reliable, functional, nor 
(especially)available as the tools they are replacing.

Once IBM get out of the mindset that "It's OK to take down the support portal 
for 24 hours, during the prime customer outage window" I might back off on this 
stance.

The RAS for the support systems needs to be as least on the same order of 
magnitude as the systems they are supporting.
The tools and mechanisms to provide this RAS are available, certainly on *IX 
and (possibly) Windoze.
IBM needs to exploit the mechanisms.

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Arwe
Sent: Tuesday, May 23, 2017 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FYI: you can request improvements to IBM Knowledge Center using the 
RFE process now

I know KC is a "popular" topic here [ducks].

Net net, you can now submit/vote/comment on KC enhancement requests on the web

Direct link:
https://www.ibm.com/developerworks/rfe/execute?use_case=changeRequestLanding_ID=0_ID=1672=17=14


if the URL parameters change incompatibly some day, that's in the RFE community 
at https://www.ibm.com/developerworks/rfe/

From the RFE community page, the simplest route I've found is to
- click in the All Products drop-down and type "know"
  (which is enough, as of today, to get you to KC...
  over time, more characters might be required)
- hit Enter to select IBM Knowledge Center
- click on the icon to the right of the product drop-down
  (looks like a bold-face greater-than sign)

--- full text ---
IBM Knowledge Center is now in the Request for Enhancement (RFE) Community, 
where external IBM product users can make suggestions for improving our IBM KC 
application and its content. Besides opening and tracking new requests, users 
can also search existing requests, and comment on them as well. The RFE 
Community provides a great opportunity for users to interact more directly with 
the IBM KC and product development teams. So we urge you to tell your customers 
about it through your interactions with them, through social media, and through 
your product documentation! Visit the RFE Community and check it out!

Related RFE Community information
Help - https://www.ibm.com/developerworks/rfe/execute?use_case=tutorials
You can find the following topics on the Help tab.
-Learn about the request process
-Learn about how to submit, view and send out notifications on requests -How to 
search for requests -How to watch for and get notified on requests -How to use 
groups
Note: You need an IBMid and password to use any feature other than Help.


--- John Arwe, IBM

--
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: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Elardus Engelbrecht]

John McKown wrote:

>>Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data 
>>base. 
>> Could not have done that with VSAM. ;-)

>​Been there. Done that. Beat up the programmer.

I hope he survived your cruel beating, because if he did the same error on the 
BACKUP RACF DB, then you can beat him up AGAIN... 8-P

   ;-D   

.. is it already Friday? 

Groete / Greetings
Elardus Engelbrecht

Gazillion years ago a colleague deleted a UCAT while initializing a volser. 
Great messy drama...  He got that our moving office trophy as a prize for the 
"best error" made in a while... ;-D

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

Re: ATTACH with RSAPF=YES

[John McKown]

On Tue, May 23, 2017 at 2:43 AM, Robin Atwood  wrote:

> Yes, the point was taken. I am now investigating using fork() to spin-off
> another address space.
>

​From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how much you're "in to" what can be done, but there are some
nice(!) facilities that fork() can leverage.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm

You can use the C language setenv() to set a number of UNIX environment
variables with can affect the results of fork() if you have the right RACF
authorities set up.

_BPX_JOB NAME can set the name of the fork'd address space (such as to the
user's name)
_B PX_USERID can set the RACF owner for the fork'd address space. The
address space doing the fork() needs some "heavy" RACF authorities for this.





>
> Thanks
> Robin
>
>

-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

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: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 23 May, 2017 0:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF Database (was: Sample JCL for file transfer using
> NJE/TCPIP)
> 
> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
> the primary RACF data base. It was not enqueued on as previously noted.
> Data was intact and the system hummed along, but there was no
> 'SYS1.RACF' in the catalog. Using backup listings, we figured out the
> exact location on the volume where the data set lived. Then we
> reallocated it using ABSTR to rebuild the VTOC entry and did a DEF NVSAM
> to rebuild the catalog entry. Some further cleanup action followed, but
> basically there was never an outage.
> 

I did exactly the same, several decades ago, with the JES2 Checkpoint. Now JES2 
allocates (and therefor enqueues) the checkpoint for already some decades. Why 
can't RACF?

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[John McKown]

On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson 
wrote:

> Brief war story. Long before "z/OS", someone accidentally deleted (!!!)
> the primary RACF data base. It was not enqueued on as previously noted.
> Data was intact and the system hummed along, but there was no 'SYS1.RACF'
> in the catalog. Using backup listings, we figured out the exact location on
> the volume where the data set lived. Then we reallocated it using ABSTR to
> rebuild the VTOC entry and did a DEF NVSAM to rebuild the catalog entry.
> Some further cleanup action followed, but basically there was never an
> outage.
>
> Could not have done that with VSAM. ;-)
>

​Been there. Done that. Beat up the programmer.


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


-- 
Windows. A funny name for a operating system that doesn't let you see
anything.

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 2.3 preview announcement (mailto:)

[גדי בן אבי]

There is a new NOTIFY JCL statement.
It will allow you to send the notification to up to 8 addresses.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, May 23, 2017 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.3 preview announcement (mailto:)

Paul Gilmartin wrote:

>  o New support is added to SAF/RACF to convert a user ID to an email address 
> and vice versa.

Will a RACF custom field be needed to be defined for the user profiles? I'm 
curious about this one.


>Will there be an OMVS SYSCALL interface to this, or will the OMVS user
>be required to issue SAF calls?  The obvious technique would be to
>enhance getpwuid(),
>  o JES2 job notification is enhanced to allow the specification of email in 
> addition to the existing NOTIFY support via local send.

You can ask 1001 questions, but I'm more concerned how JES2 and CSMTP are 
improved to receive such notification. Also I'm wondering how the e-mails are 
going to look?

I also want to have multiple persons to be notified about a job completion. If 
that is not possible, then it can be arranged that a group to be defined (at 
the receivers e-mail server)  so multiple persons are notified with one single 
mail.


>o The local part is case-sensitive and may contain special characters. 
>Apostrophes should mostly take care of this.
>o EBCDIC code pages rear their ugly heads.  I hate EBCDIC!

CSMTP can do these translations from EBCDIC, but I'm also wondering.

Let us wait until the planned availability date 29 September 2017...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

FYI: you can request improvements to IBM Knowledge Center using the RFE process now

[John Arwe]

I know KC is a "popular" topic here [ducks].

Net net, you can now submit/vote/comment on KC enhancement requests on
the web

Direct link:
https://www.ibm.com/developerworks/rfe/execute?use_case=changeRequestLanding_ID=0_ID=1672=17=14


if the URL parameters change incompatibly some day, that's in
the RFE community at https://www.ibm.com/developerworks/rfe/

>From the RFE community page, the simplest route I've found is to
- click in the All Products drop-down and type "know"
  (which is enough, as of today, to get you to KC...
  over time, more characters might be required)
- hit Enter to select IBM Knowledge Center
- click on the icon to the right of the product drop-down
  (looks like a bold-face greater-than sign)

--- full text ---
IBM Knowledge Center is now in the Request for Enhancement (RFE)
Community, where external IBM product users can make suggestions for
improving our IBM KC application and its content. Besides opening and
tracking new requests, users can also search existing requests, and
comment on them as well. The RFE Community provides a great opportunity
for users to interact more directly with the IBM KC and product
development teams. So we urge you to tell your customers about it
through your interactions with them, through social media, and through
your product documentation! Visit the RFE Community and check it out!

Related RFE Community information
Help - https://www.ibm.com/developerworks/rfe/execute?use_case=tutorials
You can find the following topics on the Help tab.
-Learn about the request process
-Learn about how to submit, view and send out notifications on requests
-How to search for requests
-How to watch for and get notified on requests
-How to use groups
Note: You need an IBMid and password to use any feature other than Help.


--- John Arwe, IBM

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

Re: z/OS 2.3 preview announcement (mailto:)

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>  o New support is added to SAF/RACF to convert a user ID to an email address 
> and vice versa.

Will a RACF custom field be needed to be defined for the user profiles? I'm 
curious about this one.


>Will there be an OMVS SYSCALL interface to this, or will the OMVS user be 
>required to issue SAF calls?  The obvious technique would be to enhance 
>getpwuid(), 
>  o JES2 job notification is enhanced to allow the specification of email in 
> addition to the existing NOTIFY support via local send.

You can ask 1001 questions, but I'm more concerned how JES2 and CSMTP are 
improved to receive such notification. Also I'm wondering how the e-mails are 
going to look?

I also want to have multiple persons to be notified about a job completion. If 
that is not possible, then it can be arranged that a group to be defined (at 
the receivers e-mail server)  so multiple persons are notified with one single 
mail.


>o The local part is case-sensitive and may contain special characters. 
>Apostrophes should mostly take care of this.
>o EBCDIC code pages rear their ugly heads.  I hate EBCDIC!

CSMTP can do these translations from EBCDIC, but I'm also wondering.

Let us wait until the planned availability date 29 September 2017...

Groete / Greetings
Elardus Engelbrecht

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

Re: ATTACH with RSAPF=YES

[Robin Atwood]

Yes, the point was taken. I am now investigating using fork() to spin-off
another address space. 

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized.  If that is not the case, we might as well end the discussion
because there is no way to do that while maintaining system integrity, and
it is unlikely anyone would accept such a "solution".

Walt Farrell has pointed out approaches that are conceivably OK.

ATTACH with RSAPF=YES should be off the table. 

Peter Relson
z/OS Core Technology Design


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

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