Specifications

96 IBM System z Personal Development Tool: Volume 3 Additional Topics
8.1 Problems starting a zPDT operation
These problems are most commonly related to devmap errors, and are often due to errors in
Linux file names in the devmap. The solution is to check the devmap carefully, remembering
that file names are case sensitive in Linux.
Problems obtaining a license (from the zPDT token) are typically due to an expired or
unactivated token.
Messages about Time Cheat errors indicate a more serious problem. These are typically
caused either by (1) moving a token between multiple PCs that do not have their time-of-day
clocks closely synchronized, or (2) manipulation of the clock in the PC. See “Token dates and
times” on page 2 for additional discussions about this.
The zPDT system uses a number of Linux shared storage (virtual memory) areas. These are
normally freed when zPDT is ended with an awsstop command. A failure or incorrect handling
during zPDT startup or operation might result in these shared storage areas not being
released. This can prevent zPDT from being started again. There are Linux commands to
individually free shared storage areas, but this requires multiple detailed steps.
1
Rebooting
Linux is a primitive but effective way to solve this particular situation.
8.2 Problems during a zPDT operation
The zPDT system maintains a number of logs and traces during operation. The zPDT
programs may detect a problem and capture the logs or traces at the time of the problem. You
can also capture logs and traces with a snapdump command
2
. This command may be used
when there is no indication from zPDT that a problem exists, but you detect a problem and
may want to work with your zPDT service provider
3
to resolve it.
It is important to remember that this discussion is solely about zPDT operation. The
snapdump data is not meaningful for addressing other problems, such as a problem with the
System z operating system or System z applications.
A snapdump function typically creates a megabyte of data in /home/ibmsys1/z1090/logs,
contained in various files. You may take as many snapdumps as you wish, remembering that
each one takes space in the logs directory. Your zPDT service provider might want several, or
one, or none of these dumps.
Files in the logs directory created by snapdump are retained until you remove them. Most other
log and trace files in this directory are automatically deleted by zPDT when appropriate.
However, over time there may be a buildup of unwanted files in the logs directory. Assuming
you are not working on an outstanding zPDT problem, you can simply delete all the files in the
logs directory (doing this when zPDT is not running). An easy way to do this is to use the
--clean option of the awsstart command. Again assuming you are not working with a zPDT
problem, you might use the --clean option every time you perform an awsstart. Conversely,
you would not use the --clean option while you are working on a problem; some of the older
log and trace files might be wanted at a later time.
The senderrdata command is used to package snapdump data into a tar file, which is
typically a little less than a megabyte. This file can be sent to IBM, via your zPDT service
1
The Linux ipcrm command can be used to remove shared resources that have been orphaned.
2
The snapdump command is valid only while zPDT is operational.
3
IBM internal users would communicate through the z1090 forum instead of through a zPDT service provider. Other
users, without a defined service provider, might use another zPDT forum.