If the time delay was between the successful authentication and the shell prompt/execution of the login script, the most common reason for delays like this is that the /var/adm/wtmp and/or /var/adm/wtmps files have grown very large.
After a successful login, HP-UX normally searches through wtmp[s] for the previous login time in order to display it to the user. If the system has a lot of logins and/or FTP server activity, the wtmp[s] files can grow very large. There is no automated wtmp[s] rotation process in HP-UX by default. Before 11.31, the SAM included a Routine Task to shorten the appropriate system logfiles, including wtmp; but in the default system configuration, it had to be run manually.
The wtmp[s] files can be truncated manually, but it is generally wise to do it when the system has no or just a few users logged in, as some tools may behave a bit oddly if used in a login session that no longer has a corresponding wtmp record. This is usually just a minor inconvenience, however.
If you can login to the system and see the shell prompt appear without a significant delay, the problem is likely elsewhere. First you should check the condition of the disk that holds the application. If it is a local disk, it might be experiencing read errors, indicating that the disk is close to a complete failure. In this case, you will typically see a lot of SCSI error messages in the "dmesg" listing and in the /var/adm/syslog/syslog.log file. If this is the reason, make sure your application and its data is backed up and have the disk replaced.
(If the system is in serious production use, you always should have mirrored disks, *and* some way of monitoring the condition of the disks. The monitoring is important: otherwise you are likely to notice a problem only when one half of the mirror has already failed, and the second half is starting to fail. By that time, some of your data may already have been damaged, and it may be impossible to replace the disks while the system is in use.)
MK
