In one of my installation of IBM z Systems Development and Test Environment (zDT) I encountered the error described below.
I invested some time to find out the root cause of the error and eventually managed to solve the situation with a workaround.

 

I'm sharing my finding for the sake of the community.

 

Symptom

The error manifests when connecting to the zDT instance using the emulated local 3270 connections (via the aws3274 device manager) to the 3270port (which usually defaults to port 3270).

For example, using the x3270 emulator, you would connect using commands such as:

x3270 -model 4 mstcon@localhost:3270x3270 -model 4 tso@localhost:3270

The emulator connects but you don't see any messages appearing in your 3270 session.

 

Software versions in use

Product, Version, Release: IBM z Systems Development and Test Environment (zDT) v10
Operating system: Red Hat Enterprise Linux Server release 7.3 (Maipo)

 

Problem analysis

Console logs "log_console_pnnnn_tYYYY-MM-DD_HH-MM-SS" shows

CMD : ddmmyy hh:mm:ss: awsstart /home/administrator/devmap/devmap.txt --clean LOG : ddmmyy hh:mm:ss: AWSSTART: z1091, version 1-6.49.23, build date - 10/21/16 for Linux on RedHat 64bitLOG : ddmmyy hh:mm:ss: AWSSTART: Intel-64 architectureLOG : ddmmyy hh:mm:ss: AWSSTART: Configuration File-/home/administrator/devmap/devmap.txt INFO: ddmmyy hh:mm:ss: STA: AWSSTA204I zPDT started in directory '/home/administrator/zDT_run_dir'.INFO: ddmmyy hh:mm:ss: STA: AWSSTA146I Starting independent 1090 instance 'administr‰⁄bô'CMD : 022817 21:08:13: awsap -p nnnn ...CMD : ddmmyy hh:mm:ss: tnportl2 -r -l -n ADMINISTR ...ERR : ddmmyy hh:mm:ss: TNPORTL2:  /tmp/ADMINISTR.0700.tcp connect failed -1ERR : ddmmyy hh:mm:ss: TNPORTL2:  /tmp/ADMINISTR.0701.tcp connect failed -1

 

 

tnportl2 logs "tnportl2_pmmmm" shows

hh:mm:ss.ssssss mmmm INFO - 3270 Listen port is 3270hh:mm:ss.ssssss mmmm INFO - ... with static instance names ADMINISTR hh:mm:ss.ssssss mmmm INFO - 2 FD(s) bound, listening FD(s): 6 7 hh:mm:ss.ssssss mmmm INFO - Connection request from xxx.xxx.xxx.xxx ...hh:mm:ss.ssssss tttttt ERROR -  /tmp/ADMINISTR.0700.tcp connect failed -1hh:mm:ss.ssssss mmmm INFO - Connection request from xxx.xxx.xxx.xxx ...hh:mm:ss.ssssss rrrrrr ERROR -  /tmp/ADMINISTR.0701.tcp connect failed -1

 

Problem diagnosis

As you may have guessed the instance is started using Unix userid: "administrator".
The unix userid is used to derive the instance name. The console logs show the instance name as 'administr‰⁄bô'
Also, the unix userid is used to derive default file name convention. The tnportl2 logs show the file name as /tmp/ADMINISTR.0701.tcp

 

My suspect is that, zDT (or better zPDT) incorrectly manages and truncates unix userid strings longer than nine (9) characters.

 

Workaround 

Based on my suspect, I defined a new user id to Unix:

# useradd ibmsys1# passwd  ibmsys1Changing password for user ibmsys1.New UNIX password:Retype new UNIX password:passwd: all authentication tokens updated successfully.

Enabled the new userid to use zPDT

$ /usr/z1090/bin/aws_bashrc (do not run as root)

Note: Depending on your security configuration you may also need to set permissions bits to zVolumes files.

 

Conclusion

As indicated above, I managed to solve the situation with a workaround: by using a different userid to start the instance.
However, I couldn't find any documented restriction on unix user ids to operate zPDT. I therefore assume that this is a software defect that manifests when using userid 'administrator'. May anyone advice?

Thanks Giovanni for your input. We will send this question to zPDT lab.

Giovanni,

I will be looking into this and will get back to you shortly.  8 character user names were standard for years and years.  I haven't looked at the code yet, but there is a good chance we are enforcing this limit.  If we are able to raise the limit, what would be acceptable to you?  Other userid/ passphrases use 100 characters as a limit.  Would this be acceptable?  I assume this i not a critical problem and a fix in the next fixpack would be sufficient?

 

RDzJohn

Hi RDzJohn,

your assumption is correct, this is not a critical problem for me. However, if there is actually a limit, having this limit in the documentation will be enough.

Giovanni,

This is actually a documented restriction (using a userid of <= 8 characters.)  The problem is this value is propagated to many places including the LPAR name.  After evaluating, we have determined that we do not like the unpredictable nature of this behavior.  As such, we will add a new message in an upcoming fixpack to detect this condition at awsstart time.  We will also add a new requirement to support userids > 8 characters in a future release.

 

RDzJohn