- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Changing f$mode() in an 'OTHER' session in ope...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2012 03:00 PM
01-04-2012 03:00 PM
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 login.com.
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 login.com properly from the software connecting to the host.
- Tags:
- ssh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2012 03:45 AM
01-05-2012 03:45 AM
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.
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2012 05:42 AM
01-05-2012 05:42 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2012 07:02 PM
01-08-2012 07:02 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-10-2012 09:16 PM
01-10-2012 09:16 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2012 07:02 AM
01-11-2012 07:02 AM
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:
http://h71000.www7.hp.com/doc/83final/9996/9996pro_109.html
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.