SW Test Automation Framework / Bugs / #1566 STAF abends U4038 reason =01 on z/OS 2.2

Sharon Lucas - 2015-12-02

You must run STAFInst to install STAF after untarring the compressed tar file for STAF. Note that if you overwrote your STAF install directory (e.g. /usr/local/staf) instead of untarring the compressed tar file for STAF to a temporary directory as the STAF Installation Guide instructs you to do, your STAF configuration file will have been overwritten (e.g. bin/STAF.cfg).

See the STAF Installation Guide (which is accessible via the main STAF web page at http://staf.sourceforge.net and then selecting "Documentation" from the navigation panel at the left) as it provides detailed instructions on how to install STAF. Section "6.5 z/OS installation" in the STAF Installation Guide at http://staf.sourceforge.net/current/STAFInstall.pdf says:

To install STAF on z/OS, you should follow the steps described in section 5 "Using STAFInst to install STAF". For example, assuming you downloaded the compressed tar file for z/OS (e.g. STAF3423-zos.tar.Z) into a temporary directory named /tmp, untar this file (which will create a subdirectory named staf) as follows:

cd /tmp compress -d STAF3423-zos.tar.Z tar -xvf STAF3423-zos.tar cd staf

To install STAF, use the STAFInst executable. To perform a recommended install of STAF into /usr/local/staf, you could run:

./STAFInst -acceptlicense -target /usr/local/staf

See section 5 "Using STAFInst to install STAF" in the STAF Installation Guide at http://staf.sourceforge.net/current/STAFInstall.pdf for a description of iinstallation options you can use when running STAFInst.

Post again if you still are having problems starting STAFProc after following the instructions in the STAF Installation Guide.

Note that you can delete temporary directory created when you untarred the compressed tar file (e.g. /tmp/staf) after you have run the STAFInst command to install STAF to the target directory (e.g. /usr/local/staf).

It is critical that you remember to make set the _CEE_RUNOPTS environment variable. Failure to set this variable will prevent STAF from working properly. The proper setting should be"

_CEE_RUNOPTS="posix(on)"

If you did not install STAF in the default target directory (/usr/local/staf), STAFCONVDIR must be set to the STAF codepage directory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sharon Lucas - 2015-12-02

assigned_to: Sharon Lucas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Vincent Getgood - 2015-12-03
  
  Sharon,
  Thanks for the information, but it does not explain why we got the first abend. Should I have done something with STAF when we upgraded, or would you expect it to work straight away?
  
  I have now sucessfully installed 3.4.23, but on starting STAF I now get: -
  
  Error creating interface.
  STAFConnectionProviderConstruct: Could not determine logical/physical identifier Error code: 22 Reason: Unknown host name: NODENAME, gethostbyname()
  
  Error in configuration file: /usr/local/staf/bin/STAF.cfg
  
  The STAF.cfg file is as is provided - no customisation done.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sharon Lucas - 2015-12-03

In general, I would have expected STAF to continue working after upgrading z/OS. However, I don't know anything about z/OS V2R2 and what changes are in it and I have not tested STAF on it. For example, with the error you are seeing now about the gethostbyname API (a C++ API, not a STAF API) not working, it would appear that upgrading to z/OS V2R2 resulted in significant changes on your system.

See question/answer "3.3.18 Explain startup error: Error creating interface. Could not determine logical/physical identifier." in the STAF FAQ at http://staf.sourceforge.net/current/STAFFAQ.htm#d0e1791 which says:

TCP/IP or DNS is probably not configured correctly which is why the gethostbyaddr API called by STAFProc is not able to determine the host name for the system. To fix this issue, you should make sure that TCP/IP and DNS are configured properly on this system. On Linux, one way that you may be able to resolve this issue is by editing the /etc/hosts file and adding a line to specify the host name for this system's IP address. For example, if your system's IP address is 9.99.100.99 and its host name is linux1.company.com, you could edit the /etc/hosts file and add the following line:

9.99.100.99 linux1.company.com linux1

The error you're seeing is not exactly the same. The cause of the "Could not determine logical/physical identifier" on your system is "Unknown host name: NODENAME, gethostbyname()". You may have an error in the local configuration of your DNS server. DNS has mappings in both directions (IP to host name and host name to IP); looks like the latter is missing. I am not a z/OS expert, but on Linux, I would use nslookup to check the configuration of the DNS server for your system's host name and IP. For example, does "nslookup yourIPAddress" work and does "nslookup yourHostName" work. I would guess "nslookup yourHostName" doesn't work which would indicate that its hostname is not in DNS.

You can also google for more information about this error. For example, I found "Diagnosing resolver problems" at http://www-01.ibm.com/support/docview.wss?uid=swg21288859 which contains information about how to solve name resolution problems on z/OS.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Vincent Getgood - 2015-12-03

Thanks Sharon.
We don't run a DNS on our z/OS systems, we use an external DNS.

This looks to have been an issue during upgrade. The z/OS 2.1 TCPIP.data parameters were overwritten by IBM supplied ones, which did not have HOSTNAME or DOMAINORIGIN coded...

We hadn't spotted that, so thanks for making us look. That'll be one less issue when we migrate the next system this weekend. We copied the parameters from z/OS 2.1, and flushed and refreshed the RESOLVER cache.

From z/OS 2.2 (TSO & Unix System Services), nslookup myhostname now works, as does nslookup myipaddress

Starting STAF still gives:-

Error on Interface definition line:

interface tcp library STAFTCP

Error code: 47
Reason : Error creating interface. STAFConnectionProviderConstruct: Could not determine logical/physical identifier.Error code: 22 Reason: Unknown host name: NODENAME, gethostbyname()

Error in configuration file: /usr/local/staf/bin/STAF.cfg

Maybe we will have to re-boot the system to get this to work?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sharon Lucas - 2015-12-03

Yes, maybe you need to reboot to get it to work as the gethostbyname() C api is still returning the same error.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Vincent Getgood - 2015-12-03

Looking at the z/OS documentation for gethostbyname(), we will at least have to restart TCPIP: -

If the HOSTNAME statement is changed, TCPIP needs to be restarted for this change to take effect.

I'll get this scheduled for sometime next week, and get back to you with an update.

I'd still like to know why STAF abended the first time. I'll have to see what happens with the system upgrade this weekend.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Vincent Getgood - 2015-12-03

As it was so late in the day, no-one was using that system. I managed to bounce TCPIP, and STAF has now started.

It doesn't explain the initial abend, but at least I have a way out if it happens again this weekend.

I'll keep you informed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Vincent Getgood - 2015-12-07

Hi.
We upgraded our main system this weekend, and Staf started up with no problem at all!

I have no idea why we got the origional abend, I think we can close this off.

Sorry for any inconvienience.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sharon Lucas - 2015-12-07

Glad there were no problems with STAF after upgrading your main system. Closing this bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sharon Lucas - 2015-12-07

status: open --> closed-works-for-me
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

STAF abends U4038 reason =01 on z/OS 2.2

Group

Searches

Help

#1566 STAF abends U4038 reason =01 on z/OS 2.2

Discussion