Thanks for that, a few other things:
- You might want to change ./UIMSERVERSTART to ./uimserverstart on page 124
- I've noticed that when creating an image environment that is automatically appends adcd to the path which means if I set it to /ZDT it will be /ZDT/adcd and if I set it to /ZDT/adcd/may2018 it will set it to /ZDT/adcd/may2018/adcd
- Some problems occur when trying to use SSH when trying to deploy an image. This is probably system specific but the sshd_config needs the PasswordAuthentication parameter set to yes
- The /var/log/zdt directory does not seem to get created:
0000094f com.ibm.zdt.rest.logic.DeployProcesses W [ZDT-LOG-WARN] Deploying image zDT from may2018 to blahblah: Failed sending script logs to the Java log directory
com.ibm.zdt.utility.ZdtException: Failed changing directory to /var/log/zdt
Original exception: No such file,error code:21002
ZdtResponse: Response code: 21002,parameters:
- Trying to deploy over SSH has some further errors:
Webserver log:
[6/17/18 12:23:31:948 UTC] 00000990 com.ibm.zdt.rest.logic.DeployProcesses I [ZDT-LOG-INFO] Deploying image zDT from may2018 to 192.168.2.126: status DOWNLOADING
[6/17/18 12:23:32:159 UTC] 00000990 com.ibm.zdt.rest.logic.DeployProcesses E [ZDT-LOG-SEVERE] Deploying image zDT from may2018 to 192.168.2.126: Returned error code 11001 with message:
stdout: <empty>, stderr: sudo: no tty present and no askpass program specified
This required some set-up in the /etc/sudoers to actually work. Probably the format of the ssh command sent by the remote system needs to be looked at
- Once all the little problems were sorted, deployment from an image repository was started and worked. A profile was created and presumably the gen2_init and clientconfig are run automatically as it looked like the system was already configured. Licenses were found and an attempt was made to IPL which failed with the message:
CPU address out of range
A small DEVMAP was created and started and no problems occurred so tried the original (aprof1) was tried again. This then failed with another problem regarding OSA:
...
Commenting out the OSA stanza allowed the z/OS 2.3 system to be IPL'ed. When looking at aprof1 it has created the OSA stanza like this:
[manager]
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y #QDIO mode
device 400 osa 3274 --unitadd=0
device 401 osa 3274 --unitadd=1
device 402 osa 3274 --unitadd=2
Whereas it should be:
[manager]
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y #QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2
---
There is a problem on the ADCD with RRS logstreams, at least IPL'ing with loadparm CS and 00:
02 ATR202D GAP FOUND IN ATR.S0W1.RM.DATA. REPLY RETRY OR ACCEPT TO ACCEPT THE DATA LOSS
Replying with retry requires the A3DBAR volume but is automatically replied to with cancel and so you get:
IXG251I IKJ56883I DATA SET IXGLOGR.ATR.S0W1.RM.DATA.A0000000 NOT
ALLOCATED, REQUEST CANCELED
ATR203I RRS COULD NOT READ FROM THE RM DATA LOG.
ATR210E INACCESSIBLE LOG DATA DETECTED ON THE RRS RM DATA 548
LOGSTREAM ATR.S0W1.RM.DATA
ATR138I ATTEMPT TO BRING UP RRS FAILED, DIAG =00000008
ATR212I RRS DETECTED LOG DATA LOSS ON 549
LOGSTREAM ATR.S0W1.RM.DATA DUE TO INACCESSIBLE LOG DATA.
LOG DATA FROM ******************* TO 2018/06/20 12:31:53 ARE AFFECTED.
ATR218I INITIALIZATION PROCESS HAS FAILED DUE TO 550
INACCESSIBLE LOG DATA IN LOGSTREAM ATR.S0W1.RM.DATA.
Replying with accept produces a dump for RRS
I do have some more questions but will save for a bit later...
Sebastian
swelton