- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Problem with group mailboxes on OpenVMS 8.4
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
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
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
тАО03-25-2011 01:28 AM
тАО03-25-2011 01:28 AM
At the moment I am porting an Alpha application from OpenVMS V7.1-2 to OpenVMS 8.4 for Integrity Servers. We use inter-process communication with mailboxes and of cource I have set the next logical:
DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP
The application consists of one main process with a bunch of subprocesses. When the main process has started, I can see the logical name pointing to its mailbox in the group table, as expected. When I start the subprocesses the logical names pointing to their mailboxes are not located in the group logical name table, but in the job logical name table. So no mailbox communication will be possible with processes outside the job tree. The main process is running in a batch job.
Does anybody recognize this? Please let me know if you have a solution.
Regards,
Cor Mom
I do have some problems with mailb
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 02:48 AM
тАО03-25-2011 02:48 AM
Re: Problem with group mailboxes on OpenVMS 8.4
Can you create a small reproducer and post it here? Having something concrete to work with makes providing a solution much easier.
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 03:31 AM
тАО03-25-2011 03:31 AM
Re: Problem with group mailboxes on OpenVMS 8.4
Do you have the GRPNAM privilege? To place a logical name for a mailbox in the group logical name table requires GRPNAM privilege.
Regards,
Ketan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 03:40 AM
тАО03-25-2011 03:40 AM
Re: Problem with group mailboxes on OpenVMS 8.4
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 03:47 AM
тАО03-25-2011 03:47 AM
Re: Problem with group mailboxes on OpenVMS 8.4
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 04:09 AM
тАО03-25-2011 04:09 AM
Re: Problem with group mailboxes on OpenVMS 8.4
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 04:24 AM
тАО03-25-2011 04:24 AM
Re: Problem with group mailboxes on OpenVMS 8.4
Your error appears to be a simple one: you believe the code works, and that "something else" other than the code is at fault. Classic debugging mistake, that.
Do not ever assume that "working code" is "correct code."
Do not fear logging.
Do not fear the debugger.
An application bug is always assumed to be the programmer's bug, until the DRI (designated responsible individual) either does prove that the bug is within the code and then fixes it, or until the DRI proves the bug is somebody else's, and provides the new DRI with information and preferably a reproducer.
As for this case...
Check the process quotas on the created processes, check the privileges within the created processes, check the translation of the associated logical names within in the context of the processes, check the run-time logs that the processes are (or should be) creating for themselves and (if the processes are not creating logs either directly under program control or somewhat less desirably as an artifact of the output for the process) add logging to the processes.
The next round of checks are for programming bugs that seemingly inevitably lurk in code that is referred to as "working code" in a forum posting.
These can include failures to check status and IOSB consistently, failure to declare an IOSB in non-volatile storage, failure to specify an IOSB whereever it is an available or optional argument, failure to handle shared memory correctly and particularly within multiprocessors, colliding access to IOSBs or event flags across asynchronous code, failure to correctly allocate event flags for use, and there exist a wide variety of other potential bugs in this particular zoo.
Variations that can arise when porting code can involve not propagating ACLs or protection masks from previous system environments, file ownership and file protection differences, differences in privileges in the default context, and subsystem identifiers.
The core of the debugging effort for these cases typically involves the aforementioned application-integrated logging, and building with and using the OpenVMS debugger, and there are various (easy) ways to implement that. What follows is an example of how a detached process can use a DECterm X Window display (on the local box or a remote X Window Server system) to display debugging activity:
http://labs.hoffmanlabs.com/node/803
Application-implemented debug logging and the OpenVMS Debugger are going to be two of the most useful approaches here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 04:31 AM
тАО03-25-2011 04:31 AM
Solution>> I can see the logical name pointing to its mailbox in the group table
How? Using the LNM extension to SDA?
>> DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$GROUP
How is that made effective in the children?
Are they started with loginout and a command file?
The old system would not have had that definition in LNM$SYSTEM did it?
And how about LIN$FILE_DEV.
Is that defined correctly ( same as on the old system ). From the sys serv ref man:
"If you redefine either LNM$TEMPORARY_MAILBOX or LNM$PERMANENT_MAILBOX, be sure that the name of the new table appears in the logical name table LNM$FILE_DEV. "
fwiw,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 05:06 AM
тАО03-25-2011 05:06 AM
Re: Problem with group mailboxes on OpenVMS 8.4
Realizwe that the redirection that you are defining is within the process table NOT the group table.
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-25-2011 05:46 AM
тАО03-25-2011 05:46 AM
Re: Problem with group mailboxes on OpenVMS 8.4
The old system would not have had that definition in LNM$SYSTEM did it?
Look what I found on the old system:
$ sh log/table=lnm$process_directory *mailbox*
(LNM$PROCESS_DIRECTORY)
"LNM$TEMPORARY_MAILBOX" = "LNM$GROUP"
$ sh log/table=lnm$system_directory *mailbox*
(LNM$SYSTEM_DIRECTORY)
"LNM$PERMANENT_MAILBOX" = "LNM$SYSTEM"
"LNM$TEMPORARY_MAILBOX" [super] = "LNM$GROUP"
"LNM$TEMPORARY_MAILBOX" [kernel] = "LNM$JOB"
That means I was searching for something that wasn't there. Of cource those subprocesses are using the system logical.
Thanks for your eye opener.
With kind regards,
Cor Mom