| The difference you see is due to DECwindows V2. I remember seeing somewhere
that V2 requires that you not muck about with the terminal in your login.com
or decw$login.com files. This is what you are doing in trying to run your
application.
Here is what to do to get around the problem.
$ if f$mode() .nes. "INTERACTIVE" then goto skipit
$ user_sm = f$getjpi("","username") + "_SM"
$ procname = f$getjpi("","prcnam")
$ if f$extract(0,f$length(user_sm),procname) .eqs. user_sm then goto skipit
<run your application>
$skipit:
The first line makes sure you don't run your application in BATCH, NETWORK,
and OTHER mode (Session Manager runs in OTHER mode).
The next lines check to see if the process name starts with "<username>_SM".
These are interactive processes that are started when you run applications on
other nodes with SET DISPLAY pointing to your workstation.
If you do any other terminal sensitive work (SET TERM/INQ, SET BROADCAST, etc.)
do it inside of a "filter" like this.
-JP
|
| This is bizzare!
I tried to duplicate the problem on my own. So, I modified my login.com file
to include the following lines:
$define sys$input sys$command
$run mortgage
$logout
Motgage is a BASIC program (EXE) that does payment computations with input
from the terminal (uses INPUT from channel 0).
I even tried changing the define to /USER.
The results matched what .0 reported. I got NO window created. Never saw the
copious output generated BEFORE these statements in my login.com. Accounting
shows a BASIC data format error as the termination status of the created
processes.
I would have thought that I would get a terminal, see the output to date, and
see it dissappear. At the very least!
At any rate, the code offered so far for login.com, should at least allow you
to start FILEVIEW, yes?
Perhaps as a work around you should start a decwindows customized application
that creates a decterm and uses the /INPUT=file. Not guaranteeing that this
would work either, but then I'm suprised what you are doing DOESN'T work!
-JP
|
| I finally received a lot of useful information from Kevin (SMAUG::)Mendel.
I post it here so that you all can benefit. There seem to be several notes
that address similar problems I had.
It is so obvious if someone pushes your nose to the right spot.
The last idea at the end of this reply did the trick.
Thank you for all your help...
---markus---
From: SMAUG::MENDEL "I don't want to burn in Paradise! 22-Feb-1990 1242" 22-FEB-1990 19:05:24.16
To: bern01::ruggiero
CC:
Subj: DECWINDOWS Note 2320
Hi.
I'm not a decwindows person or anything. I just had this problem many
times. You start an application with the session manager, it says
"xxx starting ...", and that's all that happens.
Let me see if I can help...
First, you have to remember that when SM starts an application, either
by Autostart or by Application Pull-down, it creates a new process.
This process is "username_SMn". It is an Interactive Process, but the
terminal device is a Mailbox. In this new process, Login.Com executes.
When this completes, SM sends a DCL command on the mailbox to the process.
For fileview, this command is "RUN SYS$SYSTEM:VUE$MASTER.EXE", for example.
The process reads the command from the mailbox and executes it.
Therefore, You have to make sure that your Login.COM
1) Detects when the process has been started by SM
2) If it is, doesn't do anything to the terminal.
To detect a SM-started process, what I do is check that F$MODE() is
"INTERACTIVE" *and* that the terminal device is a mailbox - that is,
f$loc("MBA",f$trn("TT")) is zero. As someone else suggested, you could
check the process name also.
Second, if it is such a process with a mailbox terminal, you don't to
do much. You DO need to define your logical names and symbols, so that
the environment is set up for the DCL command that will be read from
the mailbox. But you don't want to write to the terminal.
And you defintely don't want to run your application.
When the DCL command that comes down is "CREATE/TERM" (The DECterm
application", this creates a *second* process. This one has a window
for a terminal. Login.com executes in this process, too. This time,
the check for a mailbox fails (its a window) so you can execute your
application.
If you get the "starting" message, but nothing else happens, you need to
see the error messages that occur in Login.com. These are not logged,
because sys$output is a mailbox.
Now, to figure out what is going wrong on your station, add a line to
Login.COM that, if the process is SM-started, redefines sys$output to
a file (instead of a mailbox).
$ if (f$mode() .eqs. "INTERACTIVE") .and. -
(f$loc("MBA",f$trn("TT")) .eq. 0) then -
DEFINE SYS$OUTPUT SYS$LOGIN:SM.LOG
Then, start the application, and when the log file closes, read it. This
usually helps.
Kevin
From: SMAUG::MENDEL "I don't want to burn in Paradise! 23-Feb-1990 1014" 23-FEB-1990 16:49:39.23
To: BERN01::RUGGIERO
CC:
Subj: RE: More Info
>>> Now I want more. I tried to install my application in the 'Applications'-
>>> menu by providing a commandprocedure as the installed application.
Okay. The first question is: Does this application create it's own
window when it runs, or does it just draw to a terminal screen?
If it creates it's own window, then all you need to do (now that
your login.com is straight) is define an application definition
that is "RUN D:[D]MY_APPLIC.EXE".
If the latter, then you need to create a DECTERM to run it in.
I assume that when you execute @APPLIC.COM from DCL manually,
it works okay. Did you check?
Next: Define your application command to be
"CREATE/TERM/WAIT/INP=APPLIC.COM"
It won't work without the /WAIT. See, SM creates a process to
execute the CREATE/TERM in. The command executes, and a sub-process
is created. However, the first process then has nothing left to do,
and it exits. And that kills the sub-process, which never even had a
chance to run. So you use /WAIT to keep the first process around
until the sub-process, which is running MY_APPL.EXE, ends.
You don't need the APPLIC$STARTUP.COM if you don't want.
The CREATE/TERM/... command can be put right into the application
definition.
To test the whole configuration, you should use a simple command
procedure that does a WRITE SYS$OUTPUT "Hello" and a WAIT 0:01:00,
and get that to work first. Then, when you see a window with
"Hello", you know everything is working and you can switch the
command procedure to the one that runs my_appl.exe.
Get it?
Kevin Mendel
NAC/IBM Interconnect
Littleton, Massachusetts, USA.
From: SMAUG::MENDEL "I don't want to burn in Paradise! 23-Feb-1990 1326" 23-FEB-1990 19:31:13.64
To: BERN01::RUGGIERO
CC:
Subj: More (again)
... the previous mail slipped out before I was ready....
Instead of using APPLIC.COM, why not just try
CREATE/TERM/WAIT RUN MY_APPL.EXE
as the application definition. You don't need any command files
anywhere, don't need to redefine sys$output, or anything!
Just thought of it.
Kevin
|