在z / OS中启动的任务缺lessRACF权限

我希望testing在z / OS下运行的JDBC服务器实现。 通常的做法是定义一个JCL程序,并将其作为启动任务运行。 启动的任务需要一个用户ID才能运行。 JDBC jar被放置在一个已经安装在OMVS中的ZFS文件系统中。

已启动任务的用户需要某些RACF权限。这是由以下JCL提供的

//RUNRACF EXEC PGM=IKJEFT01 //SYSUADS DD DSN=SYS1.UADS,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * AU JDBCUSR NAME('JDBC STC USER') PASSWORD(JDBCUSR) - OWNER(IBMUSER) DFLTGRP(STCGROUP) - UACC(READ) OMVS(HOME(/u/zfs4svr) PROGRAM(/bin/sh) UID(3005) - FILEPROCMAX(131072)) RDEFINE STARTED SVRPROC.** STDATA(USER(JDBCUSR) GROUP(STCGROUP) - TRUSTED(NO)) SETROPTS CLASSACT(STARTED) SETROPTS RACLIST(STARTED) REFRESH PERMIT BPX.SERVER ACCESS(READ) CLASS(FACILITY) - ID(JDBCUSR) SETROPTS CLASSACT(FACILITY) SETROPTS RACLIST(FACILITY) REFRESH 

当我开始任务时,在SYSOUT中出现以下错误消息:

JVMJZBL1001N JZOS批量启动版本:2.4.4 2013-05-07
JVMJZBL1002N(C)版权所有IBM Corp. 2005,2012
JVMJZBL1009E在没有打印环境的情况下退出子shell进程; // STDENV不应该包含'exit'JVMJZBL1042E JZOS批量启动失败,返回代码= 101

在仔细查看并阅读IBM支持文档的内容后 ,我和我的同事们感到非常困惑。 然后,我尝试启动服务器作为一个简单的工作。 该作业的用户具有系统pipe理员权限。 这工作,我们可以testingJDBC服务器。 试图与用户一起运行该过程的结果与上面显示的错误相同。

很明显,JDBCUSR缺less一些特权或其他。 要运行服务器作为启动的任务,我需要知道什么特权缺乏。 我们当然不希望赋予启动的任务用户系统pipe理权限。

有什么方法可以找出缺less的东西吗? 这是非常令人沮丧的。

编辑11.10.2016

以下JCL是当<user>具有系统pipe理员权限时工作的JOB:

 //V4JSRV JOB USER=<user>,PASSWORD=<password>,REGION=200M //* //******************************************************************* //* Call the server as a job //******************************************************************* //PROCS JCLLIB ORDER=(ACHIM.JDBCSRV.CNTL) //SRV EXEC PROC=SRVPROC //STDENV DD DISP=SHR,DSN=ACHIM.JDBCSRV.CNTL(SRVENV) //STRCTREP DD DISP=SHR,DSN=ACHIM.JDBCSRV.STRCTREP 

该过程如下所示:

 //JDBCPROC PROC JAVACLS='de.ubs.du.jdbcserver.Server', // ARGS='-p 5431 LOG-LEVEL=FINE', // LEPARM='', // LOGLVL='+T' //JAVAJVM EXEC PGM=JVMLDM70,REGION=200M, // PARM='&LEPARM/&LOGLVL &JAVACLS &ARGS' //*JDBCPROC PROC //*JAVAJVM EXEC PGM=JVMLDM70,REGION=200M, //* PARM='de.ubs.du.jdbcserver.Server -p 5431 LOG-LEVEL=FINE' //STEPLIB DD DSN=JVA700.SIEALNKE,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //CEEDUMP DD SYSOUT=* //ABNLIGNR DD DUMMY 

正如你所看到的,这个工作只不过是运行程序而已。 当<user>是启动过程的用户名时,会产生上述错误,当它是admin用户时,则作业正常运行。 显然,要将其作为启动任务启动,proc将被复制到公共proc库(准确地说是USER.PROCLIB)。

没有什么特别壮观的。 其实这是相当平庸的。 这就是为什么我们怀疑这是一个RACF问题。

编辑(2)11.10.2016

这还不是一个解决scheme,但我已经设法本地化的问题。 已启动的过程函数(如果已分配了TRUSTED属性)。 这实际上意味着启动的任务在z / OS Unix中被视为“超级用户”(换句话说,它具有root权限)。 所以现在只需要确定我们的服务器需要什么,到目前为止只有在超级用户运行时才可用。 当我发现,我会发布一个解决scheme。

编辑(3)12.12.2016

添加跟踪(请参阅上面的修改过程)后,会出现以下错误:

 JVMJZBL2999T ->invokeMain() JVMJZBL2999T javaClassName: 'de.ubs.du.jdbcserver.Server' JVMJZBL2999T Arg 1='-p' JVMJZBL2999T Arg 2='5431' JVMJZBL2999T Arg 3='LOG-LEVEL=FINE' JVMJZBL1023N Invoking de.ubs.du.jdbcserver.Server.main()... JVMJZBL1056I Arguments to main... JVMJZBL1057I -p JVMJZBL1057I 5431 JVMJZBL1057I LOG-LEVEL=FINE JVMJZBL2999T -> JniUtil.convert() JVMJZBL2999T <- JniUtil.convert() JVMJZBL2008E Could not find or load class: de.ubs.du.jdbcserver.Server JVMJZBL2999T -> JniUtil.writeStackTrace() JVMJZBL2007E Stack trace follows: java.lang.NoClassDefFoundError: de.ubs.du.jdbcserver.Server Caused by: java.lang.ClassNotFoundException: de.ubs.du.jdbcserver.Server .at java.net.URLClassLoader.findClass(URLClassLoader.java:588) .at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:756) .at java.lang.ClassLoader.loadClass(ClassLoader.java:724) .at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:313) .at java.lang.ClassLoader.loadClass(ClassLoader.java:703) JVMJZBL2999T <- JniUtil.writeStackTrace() JVMJZBL2999T <- invokeMain() JVMJZBL2999T <- run() JVMJZBL2999T -> cleanup() JVMJZBL1014I Waiting for non-deamon Java threads to finish before exiting... JVMJZBL2999T JvmExitHook entered with exitCode=0, javaMainReturnedOrThrewException=0 JVMJZBL1042E JZOS batch launcher failed, return code=100 JVMJZBL2999T DestroyJavaVM elapsed time=0.031311 seconds, cpu time=0.021000 seconds JVMJZBL2999I JZOS batch launcher elapsed time=7 seconds, cpu time=5.090000 seconds JVMJZBL1047W JZOS batch launcher completed with Java exception, return code=100 JVMJZBL2999T <- cleanup() 

只是为什么我们得到这个运行时间错误是不清楚的。 在这个阶段,它不再是一个权限问题。

最后,我有时间回到这个问题。 原来的问题比较模糊。 看了多个论坛后,终于明白,成员ACHIM.JDBCSRV.CNTL(SRVENV)中有一个错误。 它包含的行:

 . /etc/profile 

删除这个固定的第一个错误,这是由任何bash脚本的末尾隐式“退出”引起的。 如果你正在做类似的事情,真的需要/etc/profile脚本中的设置,那么我只能build议你将脚本的内容复制到//STDENV数据中。

此后出现新的错误:

 java.lang.NoClassDefFoundError: de.ubs.du.jdbcserver.Server 

这在上面的编辑(3)中显示。 这确实是一个权限问题。 在设置RACF权限的作业中,在SYSTSIN DD中有以下内容:

 OMVS(HOME(/u/zfs4svr)... 

这为任务启动时指定了包含由JDBCUSR使用的jar的ZFS文件系统的安装点。 相应的挂载作业由pipe理员用户运行。 相关的工作步骤是:

 //REPRO EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE '<HLQ>.JDBCSRV.ZFS' SET MAXCC = 0 DEFINE CLUSTER ( - NAME('<HLQ>.JDBCSRV.ZFS') - LINEAR CYL(50 1) - SHAREOPTIONS(3,3) - ) REPRO INDATASET(<HLQ>.JDBCSRV.REPRO) - OUTDATASET(<HLQ>.JDBCSRV.ZFS) //**************************************************** //SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT), // PARM='SH mkdir -p /u/zfs4fb' //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //************************************************* //SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT), // PARM='SH chown -R JDBCUSR:STCGROUP /u/zfs4fb' //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //************************************************** //SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT), // PARM='SH chmod -R 770 /u/zfs4fb' //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //************************************************** //MOUNT EXEC PGM=IKJEFT01,COND=(4,LT) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MOUNT - FILESYSTEM('''<HLQ>.JDBCSRV.ZFS''') - TYPE(HFS) - MODE(RDWR) - MOUNTPOINT('/u/zfs4fb') 

这里的困难是, /u/zfs4fb的所有者和权限被设置为允许JDBCUSR访问,但是其中的包仍然由运行作业的用户拥有。 我们直接在OMVS中更改了内容的读/写访问权限。 这解决了这个问题。 为了解决这个问题,工作步骤的顺序需要改变。 在这种情况下,在//MOUNT步骤之后将2 //SHELCMD步骤与chmodchown命令放置在一起纠正了问题

我们的任务还有其他的问题。 在服务器的初始化中,使用了属性user.dir 。 我不确定在哪里,但似乎与JVM for z / OS有关。 这花了一些修补,因为我们无法确定价值从哪里来。 作为pipe理员用户(IBMUSER)提交的作业运行时,值为“/ u / ibmuser”。 但是,作为启动任务运行时,值为“。”,从而导致错误:

 java.lang.ExceptionInInitializerError .at java.lang.J9VMInternals.initialize(J9VMInternals.java:258) ... Caused by: java.lang.RuntimeException: default directory must be absolute .at sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:55) ... 

解决的办法是把命令cd /u/zfs4fb放在//STDENV环境脚本的末尾。 这实际上可以是STC用户(本例中为JDBCUSR)具有读取权限的任何目录。

希望这次探索之旅能帮助别人试图解决类似的问题。