Starting and Stopping COR daemon via automation

I’ve always logged in as SAGUSER post every IPL and started cor.sh manually since we installed the Data Archival product several years ago. Ok, I am finally tired of doing that!

The COR daemon and ADR extractor and accumulator run over on the OMVS side of z/OS, and Software AG is very nice to include in the libraries JCL samples for doing COR startup and shutdown from a batch job:

		//COR JOB CLASS=K,MSGCLASS=X                                 
		//COR EXEC PGM=BPXBATCH,REGION=0M,                           
		// PARM='pgm /opt/softwareag/cor/v828/INSTALL/cor.sh start'  
		//STDOUT DD SYSOUT=*                                         
		//STDERR DD SYSOUT=*                                         
                        
		//CORSTOP JOB CLASS=K,MSGCLASS=X                             
		//COR EXEC PGM=BPXBATCH,REGION=0M,                           
		// PARM='pgm /opt/softwareag/cor/v828/INSTALL/cor.sh stop'   
		//STDOUT DD SYSOUT=*                                         
		//STDERR DD SYSOUT=*                                         

So, since these are batch jobs, I can automate this, right?

However, CA-7 doesn’t have my SAGUSER info defined, and the password changes every 90 days and would need constant maintenance by our sysprogs. But these jobs have to run as SAGUSER in order to have proper access to the OMVS file system and to set proper ownership to the output files there. I don’t think we can just set USER=SAGUSER on the job card and let our production control ID submit it and expect that to work.

For anyone out there who has automated the startup and shutdown of the COR and COR daemon processes, what did you do?

Thanks in advance!

-Brian

Hi Brian,

I’m not familiar with CA-7 but COR can be run from a started task as a specific user.

You’ll probably need to run this past your sysprog/security colleagues but the principle is something like this:-

Add a member for your started task to the proclib concatenation, e.g. USER.PROCLIB(CORSTC) and then configure the started task to start at IPL time, e.g. via SYS1.PARMLIB.

//CORSTC PROC
//CORSH EXEC PGM=BPXBATCH,REGION=0M,
// PARM=‘sh /opt/softwareag/cor/v828/INSTALL/cor.sh start’
//

Using ‘sh’ rather than ‘pgm’ will avoid the task hanging around after the cor.sh script has finished. The name of started task is used as the prefix for the jobnames of the COR processes, e.g. CORSTC1 for the top-level COR process. Sending an operator ‘stop’ command to CORSTC1 will shutdown COR cleanly.

Some RACF configuration is required to run the started task as a specific user. Add a RACF profile in the STARTED class to match the name of the started task and specify SAGUSER (see IBM Documentation).

SETROPTS GENERIC(STARTED)
RDEFINE STARTED CORSTC.* STDATA(USER(SAGUSER))
SETROPTS RACLIST(STARTED) REFRESH

Hope this helps,

Best Regards,

Rob.

1 Like

Hi Rob,

Thanks for this timely response. I have a meeting already scheduled for 4 this afternoon to discuss this very topic with the sysprog and scheduling teams so having this information is much appreciated! Sounds like, if the sysprog has no issues allowing SAGUSER to be the user for started tasks, adding steps in our automation to /s procname each the startup proc and shutdown proc (or in lieu of a shutdown proc to issue a stop on a running started task) would be easy.

Thanks also for the tip on using sh instead of pgm!

Regards,

Brian

Hi Rob,

One question that came up… if we use those RACF commands to have the started task (STCCOR) run as user SAGUSER, can I still use SAGUSER as an ID with a password to log on with, or does the ID have to change to a no-password system account? The thing I am concerned if that is necessary is when I do my next upgrade to ADR, I have to ftp the files logged in as SAGUSER to preserve file ownership as SAGUSER. If this change of ID type is required, how do you handle upgrades and replacing files or modifying configuration files within version?

Regards,

Brian

Hi Brian,

A started task can be run using a normal user ID, so you should be able to keep your SAGUSER user ID as-is and continue to logon with it.

As I understand it, a ‘system’ account or what IBM call a ‘protected user ID’ just has a couple of extra attributes (NOOIDCARD/NOPASSWORD) that prevent the ID being used to enter the system anywhere a password is required.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha200/stproc.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha400/adduser.htm

Best Regards,

Rob.

1 Like

Hi Rob,

Thank you so much! You’ve been an incredible help to me. I am now thinking of all the possibilities this opens up to me for automation having this knowledge beyond my initial need. #TechForumWin

Have a great day and stay safe!

Regards,

Brian

This topic was automatically closed after 1083 days. New replies are no longer allowed.