DECWindows won't open DECterm on 2nd+later sessions

[John Gillings]

Richard,

Try logging in from another system (not at the console) and see if you can start any DECwindows applications from the command line. The example program ICO gives fairly good error messages:

$ SET DISPLAY/CREATE/TRANSPORT=LOCAL
$ RUN DECW$EXAMPLES:ICO

I'd also double check your SYLOGIN and LOGIN procedures to make sure they bypass anything interactive for non-interactive sessions.

[Richard W Hunt]

We were able to open a ticket with HP support. The bizarre behavior is probably due to something that happens after the first time you log in via the console, but here's the simple answer:

SYLOGIN has a dialog for interactive sessions. I am obviously not testing correctly for the DECWindows case in order to avoid the dialog. It appears that one of the "behind-the-scenes" DECW tasks actually goes through SYLOGIN when I didn't want it to, and my test for that case didn't stop the dialog. I will be working with HP for some sure-fire tests on how to tell when a given session can or cannot respond to a dialog.

Before anyone asks, the dialog is mandated for any session capable of interactively responding to a question. The mandate came from a level about 2 steps below the President of the USA so I won't be able to avoid having it. My "out" is that if the session isn't capable of responding, I don't have to ask in the first place. I just have to test correctly for cases that cannot respond. I thought I was doing it right but obviously I missed something.

Before I close this, I'll post what I find out from HP. Thanks for all who were trying to help.

[Richard W Hunt]

Final resolution.

For some strange reason, there are two kits with exactly the same name but different sizes and different file types for the DWMOTIF_SUPPORT for OpenVMS 8.3 on the 8.3 install kit. If somehow you copy both of these files, one is .PCSI and one is .PCSI$COMPRESSED. If you do a PROD INSTALL in a directory where both exist, you (appear) to get the .PSCI, which appears to be documentation only, instead of the compressed file with 100Kblocks+ of stuff.

I still don't know why the original install failed, but when I removed and reinstalled the product, I did so from copies of the various kits placed on a disk temporarily dedicated to the upgrae process. Somewhere along the line, the two files appeared in the same folder. When I uninstalled MOTIF from the 7.3-2 system and upgraded everything, then went back, patched all libraries, unistalled MOTIF and re-installed again (because of the STARLET.OLB patch), the wrong DWMOTIF_SUPPORT file got installed.

The fix was to go back to the original kit and grab the big SUPPORT file, remove the small file, and PROD INSTALL the support kit again. Didn't even have to reboot for it to start working correctly.

I have to believe that this was an incredibly nasty combination of a couple of old config files on the original install plus the confusion over the support kit. And yes, I verified this: The support kits differ only in the file type, .PSCI vs. .PSCI$COMPRESSED, and a PROD INSTALL by the typical approach of the name as reported by a PROD FIND picks the wrong one because it goes in alphabetic order.

Thanks to all who commented. I though I was very careful to watch my configuration, but that support file must have slipped through the cracks. Ah, well. Live and learn.

[Richard W Hunt]

Problem is now solved. I have notified HP of the potential for confusion between the two files on the 8.3 kit. They say they will consider my comments for the next release disk they have to build.