Showing results for 
Search instead for 
Did you mean: 

Changing f$mode() in an 'OTHER' session in openvms

Occasional Visitor

Changing f$mode() in an 'OTHER' session in openvms

I want to loggin in an openvms system using SSH progamatically then issue remote commands on the server. Putty will let me do that because f$mode() is 'BATCH' but with any SSH library I have used, the f$mode is 'OTHER' and that creates errors in my

Do you know of any command available to change the f$mode once connected ? I would like to change it from 'OTHER' to 'BATCH' so that I can then execute my properly from the software connecting to the host.

Respected Contributor

Re: Changing f$mode() in an 'OTHER' session in openvms

don't have a direct response to your question, but a suggestion for a solution.  I would suggest you submit a batch jobn to accomplish your task rather than trying to change the mode. I have successfully used this method in the past.  Pass along either the commands or the command file via parameters to a generic batch job for actual execution. 



Honored Contributor

Re: Changing f$mode() in an 'OTHER' session in openvms

Fixing latent errors your LOGIN.COM Is fully supported, and likely the simplest approach.


Viewed from outside, the current proposal does appear to add complexity and platform non-portability and increased support and maintenance costs toward what appears to be the goal of working around or suppressing latent application-level errors in a local LOGIN.COM procedure, rather than directly resolving the application errors in the login.


And for completeness, no; there is no supported means to alter the behavior of of the DCL lexical function f$mode(), nor of the underlying system service.  


Unsupported approaches involve patching the kernel, or patching the process creation.  These aren't easy and (if you're asking this question) probably beyond what you want to implement and support.


In general, I'd expect telnet and ssh processes would be considered "INTERACTIVE" sessions, and not "BATCH" or "OTHER" or "NETWORK" processes.  (Remote DECnet SET HOST access has been "INTERACTIVE" for eons, and not "NETWORK", for instance.)


If you simply need to detect an ssh session, then either use a particular and dedicated username for the task, or retrieve the SYS$REM_ID value and see if that works across all your local activity, or a combination of these.   Or move to a solution that isn't based on passing commands over a telnet or ssh session; that's a whole lot more difficult then it looks; it's basically screen-scraping, and that gets hairy for all but the simplest and error-free application activity.

John Gillings
Honored Contributor

Re: Changing f$mode() in an 'OTHER' session in openvms

I'd want to see some evidence that F$MODE returns "OTHER". I get INTERACTIVE for SSH sessions.


It's a simple task to instrument LOGIN.COM to display the process name and mode.



A crucible of informative mistakes
Jeremy Begg
Trusted Contributor

Re: Changing f$mode() in an 'OTHER' session in openvms

I'm very suspicious about the claim that the process mode changes from "BATCH" to "OTHER" depending on how the SSH connection is made.  So I ran some tests.


MacOS X ssh client to OpenVMS AlphaServer running MultiNet, sending command "SHOW SYM MODE" returned the result that F$MODE() is set to "OTHER" for the user's process on the VMS server.  (I set up my LOGIN.COM to define the global symbol MODE to the value of F$MODE().)


Ditto for Windows PuTTY to OpenVMS MultiNet.


When I repeated the tests to an OpenVMS AlphaServer running TCP/IP Services, the process mode was set to "NETWORK".


This illustrates a difference in behaviour between MultiNet and TCP/IP Servidces, but as expected the choice of SSH client made no difference.


The real problem here is that the LOGIN.COM doesn't handle the SSH environment correctly.

Honored Contributor

Re: Changing f$mode() in an 'OTHER' session in openvms

And in either case, the mode for an ssh interactive-user session should arguably be INTERACTIVE, and not NETWORK.  This per the DCL documentation:


A case can be made that a non-interactive user session (sftp) should be NETWORK mode, but that's not appropriate for an interactive user.


That we're even discussing (not) fixing a bug in some LOGIN.COM or SYLOGIN.COM procedure somewhere through the implementation of an inherently-more-complex change elsewhere in the platform is certainly fodder for some introspection, too.