Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

[Seymour J Metz]

z/OS TSO/E Programming Services Version 2 Release 3 
,
 specifically chapters 7 and 10, describes the TIOC/VTIOC macros.

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


From: Seymour J Metz
Sent: Friday, March 16, 2018 3:54 PM
To: IBM Mainframe Discussion List
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The VTIOC macros are the same as the old TIOC macros, with some extensions 
.

Macros like TGET, TPUT, TPG used to be in a manual called Guide to Writing a 
Terminal Monitor Program or a Command Processor; I don't recall the current 
title.




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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, March 16, 2018 3:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

PMFJI here, but you piqued my curiosity - What exactly are these VTIOC macros, 
and where would one find them?  Or are you talking about the normal VTAM SEND 
and RECEIVE processes?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Friday, March 16, 2018 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The half-duplex use of the 3270 is an application, e.g., TMP, restriction:  the 
VTIOC macros support a full duplex mode.

--

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: Loading IOCP input file using FTP

[Alan Altmark]

On Thu, 22 Mar 2018 06:48:37 +, Gadi Ben-Avi  wrote:
>I am trying to load an IOCP input file using FTP.
>The operation failed.
>
>As far as I can see, the only way to do this is using Single Object 
>Operations. Is this correct?
>
>I did not see any attempt to access the FTP server.
>Ping to the FTP server failed as well.
>
>What would the source IP be for this operation? The SE's IP address, the HMC's 
>internal IP address, or the HMC's external IP address.
>
>The computer is a z13s running HMC 2.13.1

Yes, importing or exporting an IOCP requires Single Object Operations into the 
SE.  When you get there, the task is an FTP client.  In the 2.13 level, you 
have to point it to an FTP server that is VPNed into or otherwise connected to 
the internal HMC-SE network.

At the 2.14 level, the SE will use the HMC as a gateway, obviating the need to 
break into the HMC-SE private network.  Also at the 2.14 level you can choose 
FTP, FTPS, or SFTP.

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: Cobol-Unix

[John McKown]

On Fri, Mar 23, 2018 at 10:42 AM, Seymour J Metz  wrote:

> Not even close. XCTL affects only a single RB; other RBs, loaded programs
> and allocated storage are not affected,, except as they are control blocks
> for the deleted module.
>

​Correct. But one could, and I will, argue that they are "conceptually"
similar in that XCTL "replaces" the program which invoked it while exec()​
"replaces" the entire address space. Yeah, quite a stretch, I guess.



>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Pew, Curtis G 
> Sent: Thursday, March 22, 2018 9:44 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Cobol-Unix
>
> On Mar 22, 2018, at 1:57 AM, Peter Hunkeler  wrote:
> >
> > Not answering to the question regarding command output, but I find the
> example a bit misleading. Any of the exec type UNIX functions will replace
> the current program with the new program. In MVS speak, it will end the
> current job step and initiate a new one.
> >
> >
> > I've never done this in COBOL, but I see no reason it would behave
> differently. Now assuming it does start a new job step, all DDs from the
> previous (initial) job step are lost. The new step running the "tsocmd"
> command will have no DDs at all. Also, the command will never return to the
> COBOL code. That is gone as well.
>
> I would have said that the exec type Unix functions were more like the MVS
> XCTL macro. Doesn’t the new program inherit things like open file
> descriptors from the current one? I think you’re right that the command
> will never return to the COBOL code, though.
>
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative 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
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: Sharing across two sysplex

[Martin Packer]

On TWS one nit: You can't have the hot standby be in another plex as it 
communicates with the active controller using XCF.

Probably not a show stopper.

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Jesse 1 Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   23/03/2018 16:20
Subject:Re: Sharing across two sysplex
Sent by:IBM Mainframe Discussion List 



We have several sysplexes around the enterprise. Some resources are 
'sharable', some not. 



A. Can we use a unique TWS controller to Schedule jobs on two? 

I don't know whether you can, but you don't need to. We have one 'TWS 
controller' for the whole enterprise; it controls everything. From the 
LPAR where we run the controller, most jobs get submitted to run on other 
systems/nodes. We also submit jobs to midrange (Unix). 



B. Can we use RACF RRSF to propagate our pwd over IP between them?

We have used RRSF between sysplexes for decades. We happen to use APPC for 
the purpose, but I don't see why IP would not work. Just be aware the 
AFAIK *all* RACF values will be propagated, not just passwords. I would 
seriously question whether you want all userids from production to be 
replicated on dev. That's a business decision, not a technical one.



C. Can we share dasd (write one side at a time, not pdse) with GRS (not 
MIM)?

Absolutely not. Don't even consider it. You will go down in flames.





.

.

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

Sent: Tuesday, March 13, 2018 7:51 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: (External):Sharing across two sysplex



Caught this on the newsgroup, not the LISTSERV:



--



jean.b...@ca-attica.fr



Hello. We are in the process to separate our current SYSPLEX in two : 

1. for the production

2. for the dev/qualifications. 



A. Can we use an unique TWS controller to Schedule jobs on two ? 

B. Can we use RACF RRSF to propagate our pwd over IP between them ? 

C. Can we share dasd (write one side at a time, not pdse) with GRS (not 
MIM) ? 



Many Thank's 



-



Answers:

A.  Yes, but there are recovery considerations.  Have a look at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__ibmsystemsmag.com_mainframe_administrator_tivoli_all-2Dschedules-2C-2Dall-2Dthe-2Dtime_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=SACkHo1IhhsLKFBRHQpeYGu7NlAm6NPhl86H1_9b7wo=y2iyJMpqwmErtFWlbl8FjYjOo-QM6oWsSz0JTm49K8s=


B.  Yes, but there are operational differences.  Have a look at 
http://www.redbooks.ibm.com/abstracts/sg248041.html?Open

C.  That's a nuanced question.  Can you share DASD between sysplexes? 
Sure.  Can you count on the data on the DASD being maintained with 
integrity with only GRS, probably not.  Without something like MIM, you 
will need to use some other form of serialization that spans the 
sysplexes.  The only thing I'm aware of is to use hardware 
RESERVE/RELEASE, which is fraught with its own set of management issues. 
You can search this group for probably dozens of discussions on the 
advantages/disadvantages of a hardware vs. software solution.



Do you have a need to share tapes and tape drives?  Another set of things 
to think about



Scott Fagen

CPO - 21st Century Software





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: need guide iehmove or adrdssu

[Seymour J Metz]

IEHMOVE may work, but th last time I used it, it was painfully slow.


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


From: IBM Mainframe Discussion List  on behalf of 
johnnydeep san 
Sent: Wednesday, March 21, 2018 6:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: need guide iehmove or adrdssu

Hi all,

I have confusions on which utility will full fill my task, iehmove or
adrdssu ?.

My task is to move sequential file( which has record format of  'U' )  from
volume A to volume B.  I googled but i dont get any clue . volume b is
non-sms managed.  please guide me on this . if possible please share the
link or jcl .

Regards,
--JD--

--
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: invalid ENTRY address for IDENTIFY macro

[Seymour J Metz]

There's an alternative form of Identify, used by the LOADER, that can specify 
an entry point within allocated storage not associated with any CDE.


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


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Wednesday, March 21, 2018 1:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: invalid ENTRY address for IDENTIFY macro

There is not enough information provided to give a well-reasoned
explanation.

The rule is simple: the entry point address must fit within the range
identified by the extent list (which has module start address and length)
of some module on the job pack queue or your load list (where the load
list might point to something in LPA which would not be represented in a
CDE on your JPQ).

What you need to do is to show the data that you are providing to IDENTIFY
when it doesn't work, coupled with the complete job pack queue CDEs/XTLSTs
(and, if your address is in common storage, the load list (TCBLLS).

An SVC Dump or SYSMDUMP would capture this data.

I'd watch out for whether you have the high bit on (or the low bit on, for
that matter). The address you provide is expected not to be
"pointer-defined" (i.e., not be suitable for use with BASSM).

An AMODE 24 caller of IDENTIFY will have the high byte of the entry point
address zeroed.

Could you be off by a level of indirection? Reg 1 contains the address to
be used, not the address of a word with the address to be used.

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

Re: Sharing across two sysplex

[Jesse 1 Robinson]

We have several sysplexes around the enterprise. Some resources are 'sharable', 
some not. 

A. Can we use a unique TWS controller to Schedule jobs on two? 
I don't know whether you can, but you don't need to. We have one 'TWS 
controller' for the whole enterprise; it controls everything. From the LPAR 
where we run the controller, most jobs get submitted to run on other 
systems/nodes. We also submit jobs to midrange (Unix).  

B. Can we use RACF RRSF to propagate our pwd over IP between them?
We have used RRSF between sysplexes for decades. We happen to use APPC for the 
purpose, but I don't see why IP would not work. Just be aware the AFAIK *all* 
RACF values will be propagated, not just passwords. I would seriously question 
whether you want all userids from production to be replicated on dev. That's a 
business decision, not a technical one.

C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM)?
Absolutely not. Don't even consider it. You will go down in flames.


.
.
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 Scott Fagen
Sent: Tuesday, March 13, 2018 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Sharing across two sysplex

Caught this on the newsgroup, not the LISTSERV:

--

jean.b...@ca-attica.fr

Hello. We are in the process to separate our current SYSPLEX in two : 
1. for the production
2. for the dev/qualifications. 

A. Can we use an unique TWS controller to Schedule jobs on two ? 
B. Can we use RACF RRSF to propagate our pwd over IP between them ? 
C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM) ? 

Many Thank's 

-

Answers:
A.  Yes, but there are recovery considerations.  Have a look at 
http://ibmsystemsmag.com/mainframe/administrator/tivoli/all-schedules,-all-the-time/
B.  Yes, but there are operational differences.  Have a look at 
http://www.redbooks.ibm.com/abstracts/sg248041.html?Open
C.  That's a nuanced question.  Can you share DASD between sysplexes?  Sure.  
Can you count on the data on the DASD being maintained with integrity with only 
GRS, probably not.  Without something like MIM, you will need to use some other 
form of serialization that spans the sysplexes.  The only thing I'm aware of is 
to use hardware RESERVE/RELEASE, which is fraught with its own set of 
management issues.  You can search this group for probably dozens of 
discussions on the advantages/disadvantages of a hardware vs. software solution.

Do you have a need to share tapes and tape drives?  Another set of things to 
think about

Scott Fagen
CPO - 21st Century Software


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

Re: Didn't we have this some time ago on some SLED disks? Multi-actuator

[Seymour J Metz]

IBM had one like that on the 650; three arms, which moved vertically and 
horizontally and could each access any track. I don't know which of the related 
drives, e.g., 355, 1405, had three arms.


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, March 22, 2018 9:30 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Didn't we have this some time ago on some SLED disks? 
Multi-actuator

On Thu, 22 Mar 2018 08:48:52 -0400, John Eells wrote:

>John McKown wrote:
>> https://secure-web.cisco.com/1Ny-H0J82eUTI4hG--zMt92cGYZnMAq7TZ9JoXX8asdGdNpCelJNP6ebDM5dUbyggaZ7AtZSdZOXYVjQlsmd42nYD6LbmEOaLGM9XTZ7BTV8ZTpj7Ivos2L7vTmxSQLLLuwzzolnDdSWmTRISI9z7HRn4DcOnUnEVAH-NYCUB9etrLcZu5WLL6LlpYCY-JP9qiNPka0AbPQ9qE5-BzwqCnzFZ3NdQ2LIFr3lwtxWVcHFxowv1H7Nubry3m1-8fZXBe-aFxnDioIkDKO9RrKSl6dfyW2JG3QfQFz78mUZutyt04Sq1-EtypDidpAxeZyOv78Yu_Ta4hJCS103PyfE3xVoPpdmdn27nOlK12y5gPCI3PoFc52U4tsC2JBlO82H3zukSNFwppetNZG60s9BzqeteBBQKXkVkiqpSH64NDeLfUHU9nnBoFA5CULx94eEO/https%3A%2F%2Fwww.theregister.co.uk%2F2017%2F12%2F19%2Fseagate_disk_drive_multi_actuator%2F
>>
>
>That said, it's interesting.

It would be much more interesting if both actuators could access the same
surfaces, and so the same data. The way I read it the two actuators each
access only their own set of recording surfaces.

--
Tom Marchant

--
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: Cobol-Unix

[Seymour J Metz]

Not even close. XCTL affects only a single RB; other RBs, loaded programs and 
allocated storage are not affected,, except as they are control blocks for the 
deleted module.


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


From: IBM Mainframe Discussion List  on behalf of 
Pew, Curtis G 
Sent: Thursday, March 22, 2018 9:44 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Cobol-Unix

On Mar 22, 2018, at 1:57 AM, Peter Hunkeler  wrote:
>
> Not answering to the question regarding command output, but I find the 
> example a bit misleading. Any of the exec type UNIX functions will replace 
> the current program with the new program. In MVS speak, it will end the 
> current job step and initiate a new one.
>
>
> I've never done this in COBOL, but I see no reason it would behave 
> differently. Now assuming it does start a new job step, all DDs from the 
> previous (initial) job step are lost. The new step running the "tsocmd" 
> command will have no DDs at all. Also, the command will never return to the 
> COBOL code. That is gone as well.

I would have said that the exec type Unix functions were more like the MVS XCTL 
macro. Doesn’t the new program inherit things like open file descriptors from 
the current one? I think you’re right that the command will never return to the 
COBOL code, though.


--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative 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: SMF 90 question

[William Richardson]

Martin;

To follow up on the previous response to your query I would point out a couple 
of general things...

- The SMF 90, "Subtype" 9 is really the initialization (during system IPL) of 
SMF (as opposed to the Restart of SMF - "Subtype" 15) and contains information 
about the SMF parms in use for the session.

- As previously noted, some of these Type 90's contain information about the 
responses specified during the processing of the SMF parmlib option (IPL 
"reason", etc) but these prompts are controlled by the (NO)PROMPT option 
specification and can be (are probably I suspect but can not confirm) avoided.  
   Side note: The SMFPRMxx "PROMPT" option setting also controls the 
availability of the SETSMF  console command.

- In addition to the SMF 90-9 record for "IPL" of SMF there's also the Type '0' 
IPL record which has some different parms.

In general .. these record are generated BY the SMF address space itself 
during initialization and there are others (as you pointed out) that are 
generated by other address spaces and probably lots of others that could be 
"used" to signal the event -- based on the data being collected in general.

Just some general thoughts for you.

Bill 
IBM z/OS System Software Development and Service

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

Re: SDSF JJE779S ISFJ* in z/OS 2.3

[Jousma, David]

Ah yes.  The one item I didn’t check.  My 2.2 zone is the same.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, March 23, 2018 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF JJE779S ISFJ* in z/OS 2.3

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

my 2.2 zone show that Function deleted 



Type: FUNCTION Status: DELBY HJE77A0 
FMID: 
Date/Time: 


those modules not in my 2.2 system . 





Carmen Vitullo 

- Original Message -

From: "Jesse 1 Robinson"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 23, 2018 9:56:39 AM 
Subject: SDSF JJE779S ISFJ* in z/OS 2.3 

We're installing z/OS 2.3. We find that SDSF FMID JJE779S 'SDSF JES2 Support' 
(in z/OS 2.1) is missing and 'not orderable' in ServerPac. In 2.1, this 
includes three load modules: ISFJFOR, ISFJINIT, and ISFJVER. Are these now 
obsolete? 

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


-- 
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
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: SDSF JJE779S ISFJ* in z/OS 2.3

[Carmen Vitullo]

my 2.2 zone show that Function deleted 



Type: FUNCTION Status: DELBY HJE77A0 
FMID: 
Date/Time: 


those modules not in my 2.2 system . 





Carmen Vitullo 

- Original Message -

From: "Jesse 1 Robinson"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 23, 2018 9:56:39 AM 
Subject: SDSF JJE779S ISFJ* in z/OS 2.3 

We're installing z/OS 2.3. We find that SDSF FMID JJE779S 'SDSF JES2 Support' 
(in z/OS 2.1) is missing and 'not orderable' in ServerPac. In 2.1, this 
includes three load modules: ISFJFOR, ISFJINIT, and ISFJVER. Are these now 
obsolete? 

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


-- 
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: SDSF JJE779S ISFJ* in z/OS 2.3

[Jousma, David]

All I have is this for SDSF in V2.3.   I checked my V2.2 environment, no such 
FMID there either.   SMPE knows nothing of these mods(lmods) on my system.

IZOSF230  DESCRIPTION = z/OS V2 SDSF  
  REWORK  = 2017255   
  DATE/TIME REC   = 17.293  16:54:54  
  PRODUCT = 5650-ZOS  02.03.00
  FMID= HQX77B0   

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, March 23, 2018 10:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF JJE779S ISFJ* in z/OS 2.3

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

We're installing z/OS 2.3. We find that SDSF FMID JJE779S 'SDSF JES2 Support' 
(in z/OS 2.1) is missing and 'not orderable' in ServerPac. In 2.1, this 
includes three load modules: ISFJFOR, ISFJINIT, and ISFJVER. Are these now 
obsolete?

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


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

SDSF JJE779S ISFJ* in z/OS 2.3

[Jesse 1 Robinson]

We're installing z/OS 2.3. We find that SDSF FMID JJE779S 'SDSF JES2 Support' 
(in z/OS 2.1) is missing and 'not orderable' in ServerPac. In 2.1, this 
includes three load modules: ISFJFOR, ISFJINIT, and ISFJVER. Are these now 
obsolete?

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


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

It's a miracle! | Computerworld Shark Tank

[Mark Regan]

Somewhat mainframe related.

https://www.computerworld.com/article/3264354/it-industry/its-a-miracle.html

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

Re: need guide iehmove or adrdssu

[Betsy Jeffery]

Using ADRDSSU - if you are trying to MOVE the dataset, your message of 'not 
serialized' means some other task/job/user has the file allocated.  You must 
have exclusive control to move the file.  If you are trying to copy, you will 
get the same message but it will be a warning  of 4 and the file will be 
copied.  If you want the copy cataloged, give it a new name.

Instead of 'googling' try reading the manuals.  
http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r1pdf/  is for z/OS 
2.1,  just change the v2r1pdf in the URL to the version you need.  That's 
really how to learn systems programming instead of relying on those of us that 
learn the hard way to do your research.   We (I) don't mind helping but do your 
homework first.

Regards.

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

Re: Health Check JES_NJE_SECURITY

[Stone, Marshall]

These sessions both intended and scary can be controlled by Policy Agent 
(PAGENT under z/OSMF)

Marshall Stone | Lead Engineer| Mainframe & Engineering Solutions | Enterprise 
Infrastructure and Architecture – TRICARE
101 MetLife Way, MET1 03.273, Cary NC 27513 | T. 919-907-5346 | M. 
919-324-4312| marshall.st...@metlife.com

The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Styles, Andy (ITS zPlatform Services)
Sent: Friday, March 23, 2018 2:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Health Check JES_NJE_SECURITY

This is a real possibility - I've seen it in action; a connection via NJE was 
established and an unauthenticated user was able to submit a batch job under 
the id of someone in the Security area with RACF SPECIAL access. At that time, 
our NJE network was using unsecured IP connections over port 175.
 
 
Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 22 March 2018 23:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Health Check JES_NJE_SECURITY

-- This email has reached the Bank via an external source --
 

I chatted up Tom Wasik at SHARE in Sacramento. We have a robust internal NJE 
network but no longer any outside connections. Tom raised the possibility of 
someone using a mechanism (like Python) to spoof an NJE node from within the 
closed network. I know nothing about Python, but just the prospect is 
unnerving. I think we'll pursue this (remote?) exposure to minimize the risk. 

.
.
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 Robert S. Hansel (RSH)
Sent: Friday, March 02, 2018 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Health Check JES_NJE_SECURITY

Hi Skip,

If you define  and add the name of a node to it, JES will 'trust' and 
accept any job coming from that node and propagate the submitter's ID and group 
as is. Adding a node to  is the equivalent of creating NODES profiles 
of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* 
UACC(READ). Note that NODES profiles are ignored for nodes listed in , 
so you can't do any submitting user or group translations using NODES profiles. 
 is very powerful, and nodes should only be defined to it that are 
under your control.

If a job is received from an  trusted node, and on the receiving system 
(a) the submitting user isn't defined, (b) the submitter's group isn't defined, 
or (c) the submitting user isn't connected to the group, the submitter is 
treated as an undefined user and the job may fail. This is why, as Walt 
indicated, you should only define nodes to  whose RACF databases are 
aligned for users, groups, and connects. For systems that aren't so aligned, 
don't include their nodes in  and use NODES profiles instead.

I recommend you define  in each of your RACF databases and in each such 
profile include only the nodes for the systems sharing that particular 
database. Do so even on standalone systems or Multi-Access Spool 
configurations. This will facilitate spool reloads.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
https://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 10-14, 2018
- RACF Level I Administration - APR 10-13, 2018 ** Date Change **
- RACF Level II Administration - JUN 4-8, 2018
- RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018
- RACF - Securing z/OS UNIX  - APR 23-27, 2018


-Original Message-
Date:Wed, 28 Feb 2018 19:38:33 +
From:Jesse 1 Robinson 
Subject: Health Check JES_NJE_SECURITY

APAR  OA49171 introduces a new health check called 

Date:Thu, 1 Mar 2018 03:14:36 +
From:Jesse 1 Robinson 
Subject: Re: Health Check JES_NJE_SECURITY

Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all 
totally under our control. However each node (sysplex) constitutes a different 
business environment supported by a different RACF data base. A person may have 
the same userid on sandbox 

Re: Graph database on z/OS?

[Scott Chapman]

The default encoding on z/OS occasionally causes problems. Particularly when 
doing network I/O. Adding option "-Dfile.encoding=ISO8859-1" in my experience 
takes care of those issues. Of course you have to deal with ASCII files then, 
but that's a minor issue.

Scott Chapman

On Thu, 22 Mar 2018 22:27:44 +, Graham Harris  wrote:

>Any pure java library (typically in the form of jar file[s]) should 'just
>work' on z/OS (i.e. no porting required).

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

Re: Graph database on z/OS?

[John McKown]

On Thu, Mar 22, 2018 at 5:27 PM, Graham Harris  wrote:

> John, are you specifically after a 'graph database', or a 'pure java'
> database?
>

​My area of curiosity right now is "graph database", not "java".



>
> H2 is an example of a pure java database, which is >99% zIIP eligible, in
> my experience.
>

​I've used the Derby​ database long ago, when my interest was in learning
some java.



>
> Any pure java library (typically in the form of jar file[s]) should 'just
> work' on z/OS (i.e. no porting required).
>

​That has been my experience too. I wrote a java application on Linux
(using Derby) and just binary FTP'd the resultant jar to Windows, Mac OSX,
and z/OS. It ran identically on all four platforms.​



>
> Havent quite worked out though, if Neo4j is actually a java library, or
> something that is "binaried" to specific platforms.  There seems to be a
> jar file available, but is not clear if that is the actual product, or just
> some 'helpers' to interface with java.
>

​I have downloaded the Neo4j source to my Linux home system. As far as
"language files" go, all of them that I saw were Java.​



>
> Neo4j advertises being capable of generating actual graphs from DOT
> directed graph notation, and if that is do-able from a pure java
> capability, that is something I have been patiently waiting for for many
> many years.so will be investigating that further, for sure.
>
>
> On 22 March 2018 at 16:56, John McKown 
> wrote:
>
> > I am guessing that most z/OS shops which as a true database environment
> are
> > most likely running Db2. There really isn't much else out there since
> > Oracle decided not to upgrade from 10.2 on z/OS (as best as I can tell).
> >
> > I have been reading up on graph databases. In particular, I've watched a
> > few videos on Neo4j. Some of the concepts (nodes or vertices and edges or
> > relations) seem to be similar to the old network database model, to me.
> But
> > it is very interesting. What is really interesting (again to me) is that
> > Neo4j is both open source (parts AGPL, other parts GPL) and it is written
> > in Java. Being written in Java makes it interesting since "pure Java"
> code
> > can run "for free" (no MSU usage) on a zIIP. Naturally, I have downloaded
> > the source. But I am struggling to actually get it to compile & pass its
> > tests on my Linux/Intel system. The build system is in Maven, which I
> don't
> > know. But I was thinking that it would be quite interesting to see if
> Neo4j
> > could be built and run on z/OS.
> >
> > So I'm curious if anyone else finds this interesting. And please forgive
> me
> > for not saving this for our usual "Friday" discussions of "not really
> z/OS"
> > topics.
> >
> > --
> > I have a theory that it's impossible to prove anything, but I can't prove
> > it.
> >
> > 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
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: IATUTIS - Syntaxchecker for JES3

[Norbert Friemel]

On Thu, 22 Mar 2018 23:57:23 +0530, Peter wrote:

>Hi,
>
>I am exploring the options to run JES3 inish deck checker on a live system
>to verify the syntax.
>
>https://books.google.co.in/books?id=AFnAAgAAQBAJ=PA200=PA200=IATUTIS+syntax=bl=EW-K4FfV45=6B4HzmMBb51fcjQW9QJeBtEHzEc=en=X=0ahUKEwjA9O69xYDaAhVLLo8KHa5uBoMQ6AEIKDAA#v=onepage=IATUTIS%20syntax=false
>
>I have some questions about the IATUTIS JCL,
>
>1 ) Can I run the JCL on a live system ?
Yes

>2 ) what exactly would be there to replace or contain STG1CODE dd statement
>?(sorry to ask this dummy question)
Either a PDS with (a) member(s) created by HCD (CBDMGHCP) or a dummy data set
See
 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.iata600/iat2n2_Using_MVS_Hardware_Configuration_Definition__HCD_.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.iata600/iat2n2_How_to_Run_Step_2.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.iata600/testing.htm

Norbert Friemel

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

Re: [EXTERNAL] Re: Health Check JES_NJE_SECURITY

[Sankaranarayanan, Vignesh]

Hi Skip,

Believe this is what you mean - https://github.com/zedsec390/NJElib

The script that dose this is iNJEctor.py

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Styles, Andy (ITS zPlatform Services)
Sent: 23 March 2018 06:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Health Check JES_NJE_SECURITY

This is a real possibility - I've seen it in action; a connection via NJE was 
established and an unauthenticated user was able to submit a batch job under 
the id of someone in the Security area with RACF SPECIAL access. At that time, 
our NJE network was using unsecured IP connections over port 175.


Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 22 March 2018 23:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Health Check JES_NJE_SECURITY

-- This email has reached the Bank via an external source --


I chatted up Tom Wasik at SHARE in Sacramento. We have a robust internal NJE 
network but no longer any outside connections. Tom raised the possibility of 
someone using a mechanism (like Python) to spoof an NJE node from within the 
closed network. I know nothing about Python, but just the prospect is 
unnerving. I think we'll pursue this (remote?) exposure to minimize the risk.

.
.
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 Robert S. Hansel (RSH)
Sent: Friday, March 02, 2018 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Health Check JES_NJE_SECURITY

Hi Skip,

If you define  and add the name of a node to it, JES will 'trust' and 
accept any job coming from that node and propagate the submitter's ID and group 
as is. Adding a node to  is the equivalent of creating NODES profiles 
of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* 
UACC(READ). Note that NODES profiles are ignored for nodes listed in , 
so you can't do any submitting user or group translations using NODES profiles. 
 is very powerful, and nodes should only be defined to it that are 
under your control.

If a job is received from an  trusted node, and on the receiving system 
(a) the submitting user isn't defined, (b) the submitter's group isn't defined, 
or (c) the submitting user isn't connected to the group, the submitter is 
treated as an undefined user and the job may fail. This is why, as Walt 
indicated, you should only define nodes to  whose RACF databases are 
aligned for users, groups, and connects. For systems that aren't so aligned, 
don't include their nodes in  and use NODES profiles instead.

I recommend you define  in each of your RACF databases and in each such 
profile include only the nodes for the systems sharing that particular 
database. Do so even on standalone systems or Multi-Access Spool 
configurations. This will facilitate spool reloads.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
https://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 10-14, 2018
- RACF Level I Administration - APR 10-13, 2018 ** Date Change **
- RACF Level II Administration - JUN 4-8, 2018
- RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018
- RACF - Securing z/OS UNIX  - APR 23-27, 2018


-Original Message-
Date:Wed, 28 Feb 2018 19:38:33 +
From:Jesse 1 Robinson 
Subject: Health Check JES_NJE_SECURITY

APAR  OA49171 introduces a new health check called

Date:Thu, 1 Mar 2018 03:14:36 +
From:Jesse 1 Robinson 
Subject: Re: Health Check JES_NJE_SECURITY

Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all 
totally under our control. However each node (sysplex) constitutes a different 
business environment supported by a different RACF data base. A person may have 
the same userid on sandbox and on production, but they do not necessarily have 
the same authority on both. Both represent the same person but not necessarily 
the same role.

We need to reassess our goal here.

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

Re: Health Check JES_NJE_SECURITY

[Styles, Andy (ITS zPlatform Services)]

This is a real possibility - I've seen it in action; a connection via NJE was 
established and an unauthenticated user was able to submit a batch job under 
the id of someone in the Security area with RACF SPECIAL access. At that time, 
our NJE network was using unsecured IP connections over port 175.
 
 
Andy Styles
z/Series System Programmer

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 22 March 2018 23:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Health Check JES_NJE_SECURITY

-- This email has reached the Bank via an external source --
 

I chatted up Tom Wasik at SHARE in Sacramento. We have a robust internal NJE 
network but no longer any outside connections. Tom raised the possibility of 
someone using a mechanism (like Python) to spoof an NJE node from within the 
closed network. I know nothing about Python, but just the prospect is 
unnerving. I think we'll pursue this (remote?) exposure to minimize the risk. 

.
.
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 Robert S. Hansel (RSH)
Sent: Friday, March 02, 2018 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Health Check JES_NJE_SECURITY

Hi Skip,

If you define  and add the name of a node to it, JES will 'trust' and 
accept any job coming from that node and propagate the submitter's ID and group 
as is. Adding a node to  is the equivalent of creating NODES profiles 
of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* 
UACC(READ). Note that NODES profiles are ignored for nodes listed in , 
so you can't do any submitting user or group translations using NODES profiles. 
 is very powerful, and nodes should only be defined to it that are 
under your control.

If a job is received from an  trusted node, and on the receiving system 
(a) the submitting user isn't defined, (b) the submitter's group isn't defined, 
or (c) the submitting user isn't connected to the group, the submitter is 
treated as an undefined user and the job may fail. This is why, as Walt 
indicated, you should only define nodes to  whose RACF databases are 
aligned for users, groups, and connects. For systems that aren't so aligned, 
don't include their nodes in  and use NODES profiles instead.

I recommend you define  in each of your RACF databases and in each such 
profile include only the nodes for the systems sharing that particular 
database. Do so even on standalone systems or Multi-Access Spool 
configurations. This will facilitate spool reloads.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
https://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 10-14, 2018
- RACF Level I Administration - APR 10-13, 2018 ** Date Change **
- RACF Level II Administration - JUN 4-8, 2018
- RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018
- RACF - Securing z/OS UNIX  - APR 23-27, 2018


-Original Message-
Date:Wed, 28 Feb 2018 19:38:33 +
From:Jesse 1 Robinson 
Subject: Health Check JES_NJE_SECURITY

APAR  OA49171 introduces a new health check called 

Date:Thu, 1 Mar 2018 03:14:36 +
From:Jesse 1 Robinson 
Subject: Re: Health Check JES_NJE_SECURITY

Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all 
totally under our control. However each node (sysplex) constitutes a different 
business environment supported by a different RACF data base. A person may have 
the same userid on sandbox and on production, but they do not necessarily have 
the same authority on both. Both represent the same person but not necessarily 
the same role. 

We need to reassess our goal here.

.
.
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 Walt Farrell
Sent: Wednesday, February 28, 2018 5:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Health Check JES_NJE_SECURITY

On Wed, 28 Feb 2018 18:21:03 -0500, Tom Conley  
wrote:

>I ran these on 1/5/18 to fix this check:
>
>RDEFINE RACFVARS  UACC(NONE) OWNER() RALTER  
>RACFVARS  ADDMEM()  (add one for each
>node)
>SETROPTS CLASSACT(RACFVARS) RACLIST(RACFVARS)

You should