2.1 AWSDEV908E with RC=006E

The error code "006E" indicates that the device driver is not active under OS/2 -- that is, it was not loaded successfully during CONFIG.SYS processing.

To investigate why it was not loaded, look at the C:\ISITAPE.LOG file for additional error messages.

FAQ Index

Main Menu

2.2 AWSDEV909E with RC=FF05

A device type mismatch could be caused by invalid Vendor ID and/or Product ID configuration option settings on the tape drive. For example, on an Overland T490E, the Vendor ID (option 60) must be 11 (Overland), and the Product ID (option 61) must be 32 (T490E). Setting these options to emulate some other model will interfere with the device driver's ability to properly identify the physical device and its attributes.

FAQ Index

Main Menu

2.3 AWSDEV912E: creating the VCU queue

RC is the code returned by the OS/2 DosCreateQueue request. This typically indicates that the last time that an END P/390 action was taken, OS/2 could not successfully end the device driver task (e.g., waiting on an uncompleted SCSI command). The device driver was still active when you tried to IPL the P/390 again.

The only solution is to completely shut down OS/2, restart OS/2, and do a fresh P390 IPL.

FAQ Index

Main Menu

2.4 IEC145I 413-40

You could either have a tape drive model which does not have the IDRC feature installed (e.g., a Fujitsu M2485B, Overland T480, etc.) or you do not have the tape drive defined as having the COMPACT feature on the I/O subsystem configuration of your operating system. If your tape drive does have IDRC, then verify that your I/O configuration has this feature defined for the tape unit address that you're using.

Verify that you are using the IODF file that you think you are using:

- What "System Load Parm" do you have in the P390 Configurator?
- Do you have an override parm in the "Settings" for the IPL390 icon?
- Does the LOADxx member of SYS1.PARMLIB point to the proper IODF file?

Another reason for this error message can be that you're using DCB=TRTCH=COMP (or the device is defaulting to COMP) with NL or BLP processing. COMP is only valid with SL tapes.

FAQ Index

Main Menu

2.5 IEA435I and tape drive won't vary online

It could also be that your tape unit does have the IDRC feature, but that the version of the SCSI tape device driver that you're using does not properly support the particular tape vendor and model that you have.

If you need help in using the HCD facility, you can download the HCD.DOC file from our FTP site (see DOWNLOADS on our Main Menu). Also see the IODF file tips in FAQ item 1.14.

FAQ Index

Main Menu

2.6 4mm tape drive problems (various)

1. Compression/decompression data corruption:
With XTAPE, this often appears as an "Invalid Record Type" error message when trying to verify a tape or LOAD files from a tape. The data being returned by the decompression logic of the 4mm is erroneous and XTAPE cannot identify what the record type is. An accompanying XTP090E message may show SN2=04 (hardware error) with ASC= and ASQ= codes indicating compression errors.

A bypass for this problem is to do all writing in uncompressed mode. Of course this reduces the amount of data that can be stored on one cartridge.

This kind of problem should be correctable by a firmware update but we have never known that to work. The only solution that we are aware of is to replace the entire tape drive with a newer model. For DDS-2 drives, the newer 4mm DAT drive models are recognizable by the fact that they use "jumper blocks" instead of "dip switches". Just replacing an "old model" by a newer unit which is of the "old model" style will not correct the problem. The "new model" 4mm has a new FRU number: 59H3537 (3.5") and 59H3536 (5.25").

2. Tape positioning errors:
You would see this type of error when you can read a tape sequentially from BOT without error, but when any means of fast-forward tape positioning is used (e.g., SL=x) you get data errors. This type of error often occurs when processing PID tapes. This can also be a problem when trying to read DDS-2 created tapes on a DDS-3 drive.

3. Failure to respond in the midst of I/O processing:
This error would be evidenced by cessation of tape movement (with or without the tape activity light on) and no further response from the tape processing task. Under MVS, any attempts to cancel the tape job and restart it will end up with the device being "boxed".

Usually powering the 4mm tape drive off and back on is required to clear this problem. If you have an internally mounted 4mm, you know what that means. See above for ordering a "new model" 4mm.

4. Various media errors, I/O errors:
4mm tape drives need to be cleaned frequently. Some users run a cleaning cartridge through their 4mm drive before every backup.

FAQ Index

Main Menu

2.7 OS/2 TRAP 008 and 00D errors with HPFS386

It is our understanding that 386HPFS is NOT SUPPORTED by the P/390 software package of Licensed Internal Code (LIC). You can tell if you are using the 386HPFS file system or just native HPFS by looking at the IFS= statement in your CONFIG.SYS file.

Removing 386HPFS is not as simple as just changing the IFS= statement in CONFIG.SYS because 386HPFS uses special protection attributes on several files. The good news is that it does NOT involve reformatting your disk arrays. To remove 386HPFS, you will need to run the LANINST program. LANINST can be found under the IBMLAN directory in the INSTALL subdirectory. It essentially will prompt you for all of the options to set up your system, but the key is to select "Remove 386HPFS" when given the opportunity. The "install" process will then see that everything is the same except for your request to remove 386HPFS. LANINST will then take all necessary steps to do that for you.

LANINST is supplied by IBM. The exact procedure may vary somewhat from one release to another. Any questions or problems related to the 386HPFS removal process should be directed to your OS/2 support provider.

FAQ Index

Main Menu