IBM Support

zosconnect apideploy fails with java.lang.RuntimeException default directory must be absolute

Question & Answer


Question

When I attempt to deploy the API project from the Eclipse tool, why does the tool say the APIs deployed successfully, but the APIs do not show as deployed (available) in the Eclipse tool? The messages.log from the time of deploy show Java exceptions that seem to stem from this one:

 Caused by: java.lang.RuntimeException: default directory must be absolute.

 z/OS Connect EE maintenance (2.0.1) and are
 using the latest z/OS Connect EE API Editor 2.0.100.20160617072
 
 CWWKF0015I: The server has the following interim fixes installed:
 PI51171,PI58468,PI57546,PI54855,PI52665,PI59320.
 CWWKF0012I: The server installed the following features: [ejbLite-3.2,
 servlet-3.1, ssl-1.0, jndi-1.0, jca-1.7, zosSecurity-1.0, json-1.0,
 imsmobile:imsmobile-2.0, zosconnect:zosConnect-2.0, distributedMap-1.0,
 appSecurity-2.0, jaxrsClient-2.0].

Message log shows:

 [8/3/16 19:31:01:607 GMT] 0000002a com.ibm.wsspi.webcontainer.async
                         W SRVE8025E: An error or timeout occured while
 doing async servlet processing.
 java.lang.ExceptionInInitializerError
  at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141)
  at
 java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:1
 30)
  at java.nio.file.FileSystems.getDefault(FileSystems.java:187)
  at java.io.File.toPath(File.java:2245)
  at
 com.ibm.zosconnect.internal.ApiManagerImpl.installNewApiPackage(Unknown
 Source)
  at
 com.ibm.zosconnect.internal.ApiManagerImpl.installApiFromApiArchive(Unkn
 own Source)
  at
 com.ibm.zosconnect.internal.web.ServiceProxyServlet$21.run(Unknown
 Source)
  at
 com.ibm.ws.webcontainer.async.ServiceWrapper.wrapAndRun(ServiceWrapper.j
 ava:202)
  at
 com.ibm.ws.webcontainer.async.ContextWrapper.run(ContextWrapper.java:29)
  at
 com.ibm.ws.webcontainer.async.WrapperRunnableImpl.run(WrapperRunnableImp
 l.java:74)
  at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
 a:1153)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
 va:628)
  at java.lang.Thread.run(Thread.java:785)
 Caused by: java.lang.RuntimeException: default directory must be
 absolute
  at sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:67)
  at sun.nio.fs.ZosFileSystem.<init>(ZosFileSystem.java:26)
  at
 sun.nio.fs.ZosFileSystemProvider.newFileSystem(ZosFileSystemProvider.jav
 a:32)
  at
 sun.nio.fs.ZosFileSystemProvider.newFileSystem(ZosFileSystemProvider.jav
 a:19)
  at
 sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:68)
  at
 sun.nio.fs.ZosFileSystemProvider.<init>(ZosFileSystemProvider.java:22)
  at java.lang.J9VMInternals.newInstanceImpl(Native Method)
  at java.lang.Class.newInstance(Class.java:1899)
  at
 sun.nio.fs.DefaultFileSystemProvider.createProvider(DefaultFileSystemPro
 vider.java:60)
  at
 sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.ja
 va:80)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(Fil
 eSystems.java:119)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems
 .java:100)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java
 :109)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java
 :107)
  at
 java.security.AccessController.doPrivileged(AccessController.java:594)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(File
 Systems.java:107)
  at
 java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.j
 ava:101)
  ... 11 more


After reviewing the messages.log file, I added the following xml statement to the "server.xml" file:

<zosconnect_zosConnectAPIs location="/SYSB/var/zosconnect/apis"> </zosconnect_zosConnectAPIs>

But, this resulted in the same exception.

Answer

The RACF OMVS segment for the userid associated with the STARTED task was:

HOME=/U/ZOSCON
PROGRAM=/BIN/SH

Corrections were made to the above as follows:
HOME=/u/ZOSCON
PROGRAM=/bin/sh

Then the task for z/OS Connect (BAQSTRT) was started again and now the APIDEPLOY from the GUI interface appears to be working.

I think that correcting "PROGRAM=/bin/sh" might be what made the difference.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSVVFY","label":"z\/OS Connect Enterprise Edition"},"Platform":[{"code":"PF035","label":"z\/OS"}],"Component":"","Version":"","Line of Business":{"code":"LOB17","label":"Mainframe TPS"}}]

Product Synonym

zCEE

Document Information

Modified date:
17 April 2018

UID

dwa1300605