HP 3000 Manuals

Common Problems and their Solutions [ HP DeskManager Administration ] MPE/iX 5.0 Documentation


HP DeskManager Administration

Common Problems and their Solutions 

Here are some of the possible problems which might occur with your HP
Desk system, together with possible courses of action you take.


NOTE In HP DeskManagerPLUS where maintenance is used to remedy a problem, the garbage collection and structure check phase must be set to ON in the Garbage Collection screen in Mailconfig.
A SuspectedDatabase Problem If a problem occurs whenever a particular item or message is displayed or opened, ask the System Manager to check on the number of content blocks and items. There may be special characters which are causing the problem. If you have a large scale corruption, running the Maintenance job will find any HP Desk and some IMAGE problems. The MAILUNLOAD command followed by the MAILLOAD command will then find most of the remaining IMAGE problems.
CAUTION Do not attempt to use the DBUNLOAD program in this case.
Check the MERROR report to find out where the problem has arisen. Mail Build Up A build up of mail for a mailnode can be caused by system failures, storage overflows, and so on. If you are not checking your maintenance reports and using the MAILSHOWNODE command as you should be, your first indication of mail build up will be users complaining that their messages are not being delivered. Another reason for mail building up for a particular node is inconsistencies between the information held in the Local Database and that held in the node queue. As part of its initialization, the Transport Manager scans the Local Database to check what mail has to be delivered. If it detects an inconsistency, such as a corrupt node folder, it reports it. Check to see if the Transport Manager has produced such a report and contact your Hewlett-Packard representative. The information given by the MAILSHOWNODE display or the Mail Node Summary report is an indication of possible mailnode problems. The easiest time to interpret the MAILSHOWNODE report is when all remote messages should have been sent. Any remaining messages are the cause of the problem and you can investigate them. If the deferred queues are unexpectedly high you should check that: * There is sufficient capacity at the remote location for messages. * The datacomm line is open for long enough. Deferred messages are always transmitted after normal messages. Check with the Administrator at the neighboring computer site that there is a remote computer available to receive mail from your location, and if necessary modify the availability. If a remote computer is available, it may be that a Slave Truck is not successfully logging on to the remote system. Check for this. If a Slave Truck is not logging on to the remote system, see whether or not you can log on interactively to the other system as MAILMAN.HPOFFICE. If you are able to log on, check the following: * The user and account passwords for the remote machine in the local machine's database are correct. * Type MAILMANOFF and then MAILMANON. If you cannot log on, check the following: * Data communication lines are opened correctly. * Data communication lines are operating correctly. * Sufficient pseudo terminals. * Session and job fence. * DS line number, phone number or network addressing information is correct. * Dial reply outstanding on either system. Very infrequently the Master Truck can "hang", that is it appears to log on but does not actually do anything. If this happens, it may be that you have a malfunctioning communications link and you should contact your Hewlett-Packard representative. The hung Truck can be disabled using the DISABLEMTRUCK command. If the Slave Truck is logging on, check for the following with the remote computer site's HP Desk Administrator: * The MAILSLAVEON command has been issued at the remote computer. * Computer name matches the local name of the remote computer. * There is no route returning the mail. That is, mail intended for onward delivery from the remote computer to another remote computer is instead being routed back to your computer. Examination of the listings obtained from the MAILMANOFF command will normally enable the problem to be diagnosed. Any listings generated by Slave Trucks on the remote computer are also likely to be helpful. System Failure You only need to read this if HP Desk was running when the system failure occurred. If a system failure occurs, the Recovery job runs when you next issue a MAILON command. A successful run may result in the production of the following reports which are for information only and require no action. ______________________________________________________ | | | | | Composite item children count patched | | | | Item Number 23456788 | | | | Structure check completed | | n corrupt items found of which m were patched | | | | Databases are now locked | | | | Structure Check done (1 corrupt items) | | | | Local control updated | | | ______________________________________________________ If minor errors (such as file system errors) are reported, you should shut down HP Desk, remedy them and then start up HP Desk again. Recovery may take anything up to three minutes. During this time you will not be able to use HP Desk. If you use the MAILSTATUS command, the Recovery job will be shown as running. If the Recovery job does not complete successfully, and the reports include either of these messages: ________________________________________ | | | | | Bad Basic item with children | | | | Bad composite item with content | | | ________________________________________ you should run the Maintenance job to reconcile what are, in HP Desk terms, database inconsistencies. If either the Recovery or Maintenance job fails to complete successfully and one or more of the following messages is generated: _________________________________________ | | | | | DBFIND of content chain failed | | | | DBGET of content record failed | | | | DBFIND of structure chain failed | | | _________________________________________ the IMAGE database is corrupt. You should unload and then reload the databases using the MAILUNLOAD and MAILLOAD commands. When the reload is completed, run the Maintenance job again. If the above actions prove unsuccessful, you can restore the databases from the last backup and then run the Maintenance job. Users will lose any work done since the last back up with this option. The Maintenance job is slowed down considerably if MPE is also used while it is running. If a high proportion of your users is dependent on HP Desk, you should consider: * Stopping all sessions while the Maintenance job is running. By doing this you may significantly reduce the amount of time HP Desk is unavailable, at small cost to non-HP Desk dependent users. * Running the Maintenance job concurrently. This means that the HP Desk user interface is available as soon as the databases have been stored. However, there will be a performance reduction in both the Maintenance job and the user interface. See Chapter 17 for further details. Disk Failure A disk failure requires that you recover HP Desk by restoring the last database backup, and running the Maintenance job. Unfortunately, this means that any data created since that backup will be lost. Also, because any Pending Tray copies of messages awaiting acknowledgments will have gone, the acknowledgments received from other machines will be ignored. The exception to this is the Reply acknowledgment which is treated as a message and delivered as usual. Remember to run the Maintenance job to synchronize the databases and then start up HP Desk as usual. Storage Overflow The most likely data sets to overflow are the Item-Header, Item-Structure and Item-Content data sets. If you have HP DeskManagerPLUS installed on your system, the quickest means of releasing some of the space in these data sets is by using the MAILBINEMPTY command to clear users' Waste Baskets. Alternatively, to cure the problem permanently, you will need to use the Configuration program to expand the databases. See "Expanding or Contracting the Databases" for more information. If you do not want to expand your databases at the moment, another option is to make use of the Local User Summary Report (see Chapter 21 ) and ask any users with a large number of items in any of their areas to delete any unnecessary items. If you have set disk space limits, either system wide or for individual users, you may have set them too high and should consider reducing them. Alternatively, you can ask users to transfer mail items to the MPE filing system with the HP Desk COPY command. However, you should remember that disk space is not recovered until the maintenance is run. If the lack of space is extremely severe, you might consider deleting users after first unloading them to tape using the Mailutil utility. All items associated with those users will be deleted the next time you run the Maintenance program, if those items were unique to the users. The stored users and mailnodes could be reloaded later once more space is available.
NOTE If you store users off in this way, they will lose the contents of their In Trays, Out Trays and Pending Trays, as well as any Autoanswer, Autoforward items and native names.
Regular examination of the Maintenance Summary Reports, and the data set size information output from the Garbage Collector at startup (HP DeskManagerPLUS only) will indicate the likelihood of storage overflow occurring. Once any of your data sets becomes more than 60% full, you should consider expanding your databases. None of your data sets should ever be more than 85% full. See "Monitoring HP Desk" earlier in this manual. Line Failure Failure of a data communication line causes no problem other than delay. Any delay can be avoided if an alternative route or routes to the mailnode or mailnodes in question can be found. If this is not possible and the line is likely to be down for some time, it might be prudent to consider using another form of transport such as magnetic tape, using the EFT facility. If you do not have an alternative route configured and the line failure is likely to last for some time, then temporarily delete the affected mailnodes to avoid a build up of mail and possible storage overflow. Software Failure Should any of the HP Desk programs abort it is important to try and find out what went wrong. HP Desk automatically creates a deferred spoolfile, Desklog, which contains diagnostic information. This output should be made available to your Hewlett-Packard representative. Also keep any stack dumps that you make. Corruption of the database is unlikely to result from, but may cause a software failure. As detailed above, another possible reason for failure is storage overflow; that is, there is not enough space left in the database to complete the requested action. A common symptom of this condition is the report of a serious error whenever the SEND, FORWARD, REPLY, COPY, or CREATE commands are used. Errors While Processing EFT/FSC Messages If an EFT or FSC Slave Truck is unable to bring in a file or a particular message within a file, you need to check the job listing to find out the cause. It could be that the database is nearly full and has insufficient room for a large message. Alternatively the ARPA header may be badly or inaccurately formatted. The Slave Truck's IPC file contains a reference to the message file at fault. When an error occurs, the IPC file is copied to the error IPC file corresponding to the EFT/FSC format used: EFT ERRIPCIN.MAILDB.HPOFFICE ARPA Standard/Compressed ERRARPA.MAILDB.HPOFFICE ARPA Reference ERRAREF.MAILDB.HPOFFICE Details of the error are written to the $STDLIST of the Slave Truck. You can resubmit these messages when you have rectified the problem that caused the messages to be placed in the error file. To resubmit them use the appropriate MPE command: FCOPY FROM=ERRIPCIN.MAILDB.HPOFFICE; TO=EFTIPCIN.MAILDB.HPOFFICE FCOPY FROM=ERRARPA.MAILDB.HPOFFICE; TO=ARPAIPC.MAILDB.HPOFFICE FCOPY FROM=ERRAREF.MAILDB.HPOFFICE; TO=AREFIPC.MAILDB.HPOFFICE


MPE/iX 5.0 Documentation