So no matter if you have RACF,TSS,ACF2 - RACF is always started - similar to early code for DB2.
Then once the system gets up far enough, you can start RACF,TSS,ACF2 So what are you seeing where you have a question about "who is starting RACF" So two separate phases for RACF. And yes, I did simplify this a bit. Lizette -----Original Message----- >From: Tony Thigpen <[email protected]> >Sent: May 21, 2019 9:10 AM >To: [email protected] >Subject: Re: IPL process - understanding IEFSSNxx > >Thanks. That helped a lot. > >One of the questions I am trying to answer is "who is starting RACF >during IPL". It's not in COMMNDxx. > >Tony Thigpen > >John McKown wrote on 5/21/19 10:56 AM: >> On Tue, May 21, 2019 at 9:47 AM John McKown <[email protected]> >> wrote: >> >>> On Tue, May 21, 2019 at 9:27 AM Tony Thigpen <[email protected]> wrote: >>> >>>> I am looking at my ipl process and am trying to understand why some of >>>> the start by themselves. >>>> >>>> I am in a sandbox so I can play all I want. >>>> >>>> My current IEFSSN00 is: >>>> 000001 SUBSYS SUBNAME(SMS) >>>> 000002 INITRTN(IGDSSIIN) >>>> 000003 INITPARM('ID=00,PROMPT=DISPLAY') >>>> 000004 SUBSYS SUBNAME(JES2) /* JES2 AS PRIMARY SUBSYSTEM */ >>>> 000005 PRIMARY(YES) START(YES) >>>> 000006 SUBSYS SUBNAME(RACF) >>>> 000007 INITRTN(IRRSSI00) >>>> 000008 INITPARM('%,M') >>>> 000009 SUBSYS SUBNAME(CICS) >>>> 000010 SUBSYS SUBNAME(DFRM) /* NAME OF THE DFSMSRMM SUBSYSTEM */ >>>> 000011 INITRTN(EDGSSSI) >>>> 000012 SUBSYS SUBNAME(TNF) >>>> 000013 SUBSYS SUBNAME(VMCF) >>>> 000014 SUBSYS SUBNAME(FFST) >>>> 000015 SUBSYS SUBNAME(IXFP) /* IXFP SUBSYSTEM */ >>>> 000016 INITRTN(SIBSSIPL) >>>> 000017 INITPARM('INIT(Y),DYNDDSR(I),LANG(AMENG)') >>>> >>>> I understand that JES will start because of the START(YES), but I am >>>> also seeing other sub-systems like RACF start. >>>> >>>> Does the INITRTN force an autostart as if START(YES) was specified? >>>> >>> >>> I don't think so, but I can't be definitive. The INITRTN specifies a >>> program which will run in the master scheduler address space during start >>> up. Now, that program could do a START command, via SVC 34. Or even use the >>> ASCRE to create a new address space to run some code which might stay >>> around "forever". A case of "who knows unless it is documented". >>> >> >>> >>>> >>>> It appears that jobs started with IEFSSNxx start as normal JES jobs. Can >>>> IEFSSNxx be used to start tasks which run as SUB=MSTR. >>>> >>> >>> >>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae200/iefssn1.htm >>> >>> >>> - Once a subsystem name is defined to the system, any attempt to start >>> that subsystem (or any started task with the same name as that >>> subsystem) >>> via a START command which does not explicitly specify SUB=JES2 (or JES3) >>> will result in that subsystem or started task being started under the >>> Master subsystem rather than under the job entry subsystem. Because the >>> only procedure libraries available to the Master subsystem are those >>> specified in the MSTJCLxx's IEFPDSI data set, any procedures being >>> started >>> that are defined in the job entry subsystem's PROC00 data set, but not >>> in >>> the MSTJCLxx's IEFPDSI data set, will be unavailable. Therefore they >>> will >>> not be found; the system will issue message IEFC612I. >>> >>> >> >> I forgot to mention. It might _appear_ that the subsystem is running under >> JES when it is actually running SUB=MSTR if the code does an SSI function >> code 20 "Request Job ID". That will connect it to the primary JES so that >> it can do things such as dynamically allocate SYSOUT. >> >> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaf200/rjobid.htm >> >>>> -- >>>> Tony Thigpen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
