Operating System - OpenVMS
1748246 Members
3749 Online
108760 Solutions
New Discussion

Re: Run Program at Login

 
SOLVED
Go to solution
gbarcalow
Occasional Advisor

Run Program at Login

I could really use some help with my login procedure.

I added, to the end of my login.com, the command to execute and start our main user interactive program instead of dropping users at the $ to run the command themselves. The program starts okay and prompts the users to login (with program specific credentials) but the keyboard doesn't work. I can't type letters or numbers. I can CTRL+C to get back to the $, run the program again manually and all is fine.

* Update: Running the program form any com file has the same result, it's not limited to the login.com. I created another com file, all it does is start the program and the result is the same. I can't type my usename.

Any ideas would be greatly appreciated. Even a sample login menu, or something.

Thanks in advance.

5 REPLIES 5
Steven Schweda
Honored Contributor

Re: Run Program at Login

> [...] but the keyboard doesn't work. [...]

   Does your "main user interactive program" get its input from
SYS$INPUT (C "stdin")?  That's defined differently in a DCL script:

ITS $ type test.com
$ show logical sys$input
ITS $ @ test.com
   "SYS$INPUT" = "_ITS$DKA1:" (LNM$PROCESS_TABLE)

   That is, it's the (text in) the DCL script itself (thus, the disk
device name), not the user's terminal.  SYS$COMMAND, on the other hand,
may be what you want:

ITS $ type test2.com
$ show logical sys$command
ITS $ @ test2.com
   "SYS$COMMAND" = "_ITS$FTA411:" (LNM$PROCESS_TABLE)

   So, in the DCL script, before running your "main user interactive
program", try:

      $ define /user_mode sys$input sys$command

(The "/user_mode" option causes this redefinition to evaporate when the
next executable image (your program) exits.)

gbarcalow
Occasional Advisor

Re: Run Program at Login

First, thank you for your reply. Below are the results of the commands you mentioned. I'm not a VMS person, but to me, it looks like the session is getting it's input from the terminal. But, I put your command in there anyway and voila, it works. You sir are my new hero. 1M thanks to you.

$ show logical sys$input
"SYS$INPUT" = "_TNA57506:" (LNM$PROCESS_TABLE)
$ show logical sys$command
"SYS$COMMAND" = "_TNA57506:" (LNM$PROCESS_TABLE)

Steven Schweda
Honored Contributor

Re: Run Program at Login

> [...] to me, it looks like the session is getting it's input from the
> terminal. [...]

   Most likely, it's getting its input from SYS$INPUT, but the value of
that logical name depends on your environment.

> $ show logical sys$input
> "SYS$INPUT" = "_TNA57506:" (LNM$PROCESS_TABLE)
> $ show logical sys$command
> "SYS$COMMAND" = "_TNA57506:" (LNM$PROCESS_TABLE)

   Yup.  In an interactive environment, both SYS$INPUT and SYS$COMMAND
normally point to your (Telnet-connected?) terminal.  But, if you stick
those commands into a DCL script (as I did, above), and execute (@) that
script, then you'll see that SYS$INPUT is different, and your program
will try to read its input from the DCL script (SYS$INPUT), not the
terminal (SYS$COMMAND).  Redefining SYS$INPUT to SYS$COMMAND puts things
back to the way they were when the program was run interactively, with
SYS$INPUT pointing to your terminal.

   If your program accepts interactive commands, like, say, "help" and
"exit", then you could write a DCL script which does those:

      $ run main_user_interactive_program  ! Or whatever you do.
      help
      exit

Execute (something like) that, and see what happens.  Note that DCL
normally stops reading input from the script when it sees a line
beginning with "$" (but see HELP DECK for more fine print).

gbarcalow
Occasional Advisor

Re: Run Program at Login

So, it's only partially working. There are commands inside the program "functions" that pull up different features/utilities. I always thought they look like part of the main program, but now I am guessing they are not, because some of the functions run into the same problem as the login screen. I can login and navigate the program quite a bit, but there are two functions that, once I enter them the keyboard no longer types.

Is there a way to make that command perpetual for the duration of the session instead of just the next command?

Steven Schweda
Honored Contributor
Solution

Re: Run Program at Login

> [...] There are commands inside the program "functions" that pull up
> different features/utilities. [...]

   Ok.  If the magic program is not a monolith, then /USER_MODE may be
too gentle.

> (The "/user_mode" option causes this redefinition to evaporate when the
> next executable image (your program) exits.)

   Close to true.  For more accurate fine print:

      HELP DEFINE /USER_MODE

   So, for example, a spawned subprocess would also be unaffected by a
/USER_MODE logical name definition.

> Is there a way to make that command perpetual for the duration of the
> session instead of just the next command?

   Without /USER_MODE, that logical name definition would persist.  If
running the magic program is the last thing you'll ever do in that DCL
script, then it may not matter.  If you'll be doing other stuff after
the magic program exits, then you might want to do something more like:

      $ define sys$input sys$command
      $ run main_user_interactive_program  ! Or whatever you do.
      $ deassign sys$input

   Everything's complicated.