Finalmente, tive tempo de voltar a este problema. O problema original era bastante obscuro. Depois de olhar para vários fóruns, finalmente ficou claro que havia um erro no membro ACHIM.JDBCSRV.CNTL (SRVENV). Ele continha a linha:
. /etc/profile
Remover isso corrigiu o primeiro erro, que foi causado pela "saída" implícita no final de qualquer script bash. Se você estiver fazendo algo semelhante e realmente precisar das configurações no script /etc/profile , só posso sugerir que você copie o conteúdo do script para você //STDENV data.
Depois disso, um novo erro apareceu:
java.lang.NoClassDefFoundError: de.ubs.du.jdbcserver.Server
Isso foi mostrado na edição (3) acima. Isso acabou por ser um problema de permissões. No trabalho para configurar as permissões do RACF, há o seguinte no DD SYSTSIN:
OMVS(HOME(/u/zfs4svr)...
Isso especifica um ponto de montagem para o sistema de arquivos ZFS contendo os jars usados pelo JDBCUSR, quando a tarefa é iniciada. O trabalho de montagem correspondente foi executado por um usuário administrador. Os passos relevantes da tarefa são:
//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')
A dificuldade aqui foi o fato de que o proprietário e os direitos para /u/zfs4fb estão configurados para permitir acesso ao JDBCUSR, no entanto, os pacotes contidos ainda são de propriedade do usuário que executa o trabalho. Alteramos o acesso de leitura / gravação para o conteúdo diretamente no OMVS. Isso resolveu o problema. Para corrigir isso no script, a ordem dos passos de trabalho precisa ser alterada. Nesse caso, colocar as etapas de 2 //SHELCMD com os comandos chmod e chown após a etapa //MOUNT corrige o problema
Houve outras questões com a nossa tarefa. Na inicialização do servidor, a propriedade user.dir é usada. Eu não tenho certeza apenas onde, mas parece ter a ver com a JVM para z / OS. Demorou um pouco de ajustes, já que não pudemos determinar de onde vem o valor. Quando executado como um job submetido por um usuário administrador (IBMUSER), o valor era "/ u / ibmuser". No entanto, quando executado como uma tarefa iniciada, o valor era ".", O que causou o erro:
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)
...
A correção foi colocar o comando cd /u/zfs4fb no final do script do ambiente //STDENV . Isso pode realmente ser qualquer diretório para o qual o usuário STC (neste caso, JDBCUSR) tenha permissão de leitura.
Espero que este tour de descoberta ajude alguém a tentar resolver problemas semelhantes.