Global Sections: How to find out processes that are attached

[Bernado Pehar_1]

Hi all,

we have had some problems recently because we couldn't recreate some global sections since there were still some processes around that had them mapped. We couldn't find a way how to find out which processes were still attached. With show dev /file we could only see the 000000 PID, and with analyze/system I just couldn't find the information needed to track the processes down.
Does anybody of you know a good method of achieving this ?

[Kumar_Sanjay]

What Global section you are creating.
would please put some more details?
How you are creating the global section and what error you are getting?

Cheers.

[Bernado Pehar_1]

Hi,

we are creating a temporary global section. What exactly would you like to know ?

Regards,

Bernado

[Kumar_Sanjay]

Would you please post the error message?

[Bernado Pehar_1]

Hi,

the error message is following:

%RMS-E-FLK, file currently locked by another user

We want to delete the section file and recreate it with another size. Problem is there are still processes having the old one mapped, and the question is how to find out who is mapping a global section.

Regards,

Bernado

[Kumar_Sanjay]

You can't delete a global section with DCL or INSTALL. You need to find the appropriate DECedi shutdown program to clean up and issue a $DGBLSC system service, to mark that global section for deletion. When the last process, which has mapped that section, exits, then the global section will be deleted.

A reboot will always help ;-)

Otherwise have a look with INSTALL LIST/GLOBAL/FULL and see, if you can find that global section. It may already be on the 'Delete Pending Global Sections' list.

If it's still installed and not on the delete pending list and you can't find the DECedi program to shut down this section, you may be able to write a little program using $DGBLSC to delete the section.

If it's on the delete pending list, you'll need to find, which processes are still mapped to that section:

$ ANAL/SYS
SDA> SHOW GSD/DELETE

SDA> SHOW GST/SECTION_INDEX=xx ! xx= GSTX

Then you'll find the WCB (Window Control Block) address in the 'Window' column.

SDA> SET OUT/NOINDEX x.x
SDA> SHOW PROC/CHAN ALL
SDA> EXIT

[Bernado Pehar_1]

Hi,

since it is a not a permanent global section, it should be unmapped when all processes have disconnected it. We now found out there was a user executing an interactive program that maps this section in question who exited the application by issuing Ctrl/Y without typing stop or exit at dcl prompt afterwards. So he still had the sections mapped since the image was only interrupted, but not run down.

I found that last part of your reply in another thread on this forum already

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1204412

and have tried it out, but it didn't yield success, so I thought this might be due to the fact the user interrupted the executable.
I'll try to see if I can get more Information from analyze/system...

Regards,

Bernado

[Willem Grooters]

The last freeware CD (FREEWAREV80) contains SDA extension GBLSEC$SDA for getting this information.

[Wim Van den Wyngaert]

Can you try @ of the enclosure with P1=part of the section file ?

It will scan all process channels.

fwiw

Wim

[Wim Van den Wyngaert]

Before @ do
$ D == "write sys$output"
(is in my login)

Wim

[Bernado Pehar_1]

@William,

a colleague of mine provided me with the tool, but it tells me 0 processes found :-(

@Wim,

the tool doesn't generate any output. I searched the workfiles, but here, too, the section is not found.

I'm going to post an example with one section currently in use and my attempts with the various tools to determine the processes. Maybe this helps illustrating the problem a bit. Just hang on a little while until I gather the output.

Regards,

Bernado

[Hoff]

Related reading material follows...

http://h71000.www7.hp.com/wizard/wiz_3365.html
http://h71000.www7.hp.com/wizard/wiz_3530.html
http://h71000.www7.hp.com/wizard/wiz_3635.html
http://h71000.www7.hp.com/wizard/wiz_3768.html

Personally, I prefer to use RMS files with global buffers enabled (rather faster than you might think, already fully distributed and cluster-aware, and it deals with all the corner cases for you), or failing that (and when requiring use of shared memory) I'd tend to use global section system services and not installed shareable images.

Example code:
http://h71000.www7.hp.com/wizard/wiz_2486.html

Shared memory gets ugly regardless, as you (unless you use RMS here) have to deal with the processor caches and SMP. Some further details are here:

http://h71000.www7.hp.com/wizard/wiz_2637.html
http://h71000.www7.hp.com/wizard/wiz_2681.html
http://h71000.www7.hp.com/wizard/wiz_6984.html

Some virtual memory and cache-related topics:
http://64.223.189.234/node/228
http://64.223.189.234/node/401
http://64.223.189.234/node/407

Installed shareable images are not my favorite OpenVMS construct; they (as you're discovering) tend to have issues around maintenance and upgrades.

As for the specific ^Y case with that outside image, you might want to make that a privileged image (to cause a rundown on ^Y) or you might want to add a ^Y handler into the tool. Here's an example of the latter:

http://64.223.189.234/node/1099

[Bernado Pehar_1]

Hi,

so here is the example:

We have following global section that is mapped by a couple of processes on the node:
PND_XSVFR_BOARD-DF0004-61

My first approach was following:

DF0004_PND61> pipe show dev /file u1$: | grep PND_XSVFR_BOARD-DF0004-61
00000000 [USER.PND61EXCH61]PND_XSVFR_BOARD-DF0004-61.SECTION;1

But here I only see the 0000000 PID as the owner process of the file ( makes sense ).

Now let's try with the GBLSEC Tool from the Freeware CD:

DF0004_PND61> define gblsec$sda u1$:[bpehar]GBLSEC$SDA.EXE

DF0004_PND61> anal/sys

OpenVMS system analyzer

SDA> gblsec PND_XSVFR_BOARD-DF0004-61
GBLSEC V1.2 (c) 2005, Ian Miller (miller@encompasserve.org) built on VMS V8.3

Press RETURN for more.
SDA>

Global section: PND_XSVFR_BOARD-DF0004-61
-----------------------------------------
GSD: Global Section Descriptor
GSName: PND_XSVFR_BOARD-DF0004-61
PCBUIC: [1075,1]
FILUIC: [175,77]
ORB: 94799248
GSTX: 00000341
PROT: 0000FFFF
IDENT: 00000000
IPID/RGSTX: 00000000
FLAGS: 00C283CD
WRTMOD = USER, AMOD = USER, GBL DZERO WRT SYS

File: DISK50:[USER.PND61EXCH61]PND_XSVFR_BOARD-DF0004-61.SECTION;1

GSTE: Global Section Table Entry
GSD: A8F53820
PFC: 0.
WINDOW: 934064C0
VBN: 1

Press RETURN for more.
SDA>

Global section: PND_XSVFR_BOARD-DF0004-61
-----------------------------------------
REFCNT: 11.
UNITCNT: 16.
VPX: 8464.
FLAGS: 00C283CD
WRTMOD = USER, AMOD = USER, GBL DZERO WRT SYS
%GBLSEC-I-SEARCHING, searching for processes mapped to this global section
0 processes found to be mapped to this global section

Now trying with the tool of Wim:
DF0004_PND61> @x PND_XSVFR_BOARD-DF0004-61
DF0004_PND61>

Now with the approach from the other thread as suggested by Volker Halle:

DF0004_PND61> anal/sys

OpenVMS system analyzer

SDA> show gst/section=163

Global Section Table
--------------------

Index Address Sect/GPTE Addr GSD Pagelets VBN Window R
efcnt Flink Blink Flags
-------- -------- ----------------- -------- -------- -------- -------- --
------ ----- ----- --------------------
00000163 9000DD70 FFFFFEFE.9FE6D528 A8F66340 00000010 00000001 91F36980 00
00000A 0163 0163 WRT AMOD=USER SYSGBL
Name = PND_XSVFR_BOARD-DF0004-61
File = DSA60:[USER.PND61EXCH61]PND_XSVFR_BOARD-DF0004-61.SECTION;1

SDA> set out home:x.x /noinde
SDA> show proc /chan all
SDA> set out sys$output
SDA> exit
DF0004_PND61> sea home:x.x 91F36980
%SEARCH-I-NOMATCHES, no strings matched


@Hoff: I'm going to have a look at the 'Ask the wizard' Topics you mentioned. I already have been searching the 'Ask the wizard' archives for topics mentioning global sections as well as the information offered under the Section "Questions frequently asked by Partners". I guess this time I'll really have to dig deeper into VMS to find out.
The implementation of an interrupt handler will be considered definitely, so this situation should at least be prevented.

Regards,

Bernado

[Hoff]

Despite what Kumar_Sanjay wrote a while back, you *can* (sometimes) delete (certain) global sections with INSTALL. Here, I'd figure out if this is a common (as it certainly appears to be) and then that's exactly what I'd try.

As a start...

INSTALL LIST /FULL filespec

Kumar_Sanjay's comments are correct in the general case, but the INSTALL utility itself uses global section system services as part of its implementation. There's a subtlety or three here. You definitely don't want to mix the global section services with the INSTALL mechanism if you can avoid it, but the two are still and confusingly somewhat interrelated. And sometimes you DO use INSTALL to expunge a section. What is known as a Fortran-style common or an installed-writable shareable image does have associated section(s), but does use INSTALL.

And as for a variant approach for the ATW area, download the wizard.zip archive that's offered over there (it was listed at the bottom of the main page, IIRC) and unpack it. Far easier and far faster to search all that.

[x2084]

The SDA output doesn't match the output from the tool: the tool says DZERO, which doesn't make sennse to me, for file based writable global sections.

The "Name" shown by SDA indicates that this is not a writable shareable image installed with the INSTALL utility, it is a file based global section, created with $crmpsc. INSTALL creates a name from the KFE address, in hex, the "INS$" prefix and the and a suffix "_nnn" with nnn being the number of the image section, starting with 1. So there is no way to delete it with INSTALL.

[On the other hand, if you remove an installed iamge with INSTALL, and the image is in use, mapped, then the global section is still there: therefore the KFE address in the name.]

You may want to check, if the channel to the file was $deassgn'ed after calling $crmpsc. Then you may not see an open channel in any process.

[Ian Miller.]

Regarding the DZERO in
FLAGS: 00C283CD
WRTMOD = USER, AMOD = USER, GBL DZERO WRT SYS

The code checks for (SEC$M_DZRO 0x4) being set and if it is displays DZERO. 'tis strange though.

I see REFCNT: 11. - I think this has to be 0 before the global section will be deleted.

[Volker Halle · Accepted solution]

Bernardo,

there are some differences in the section information displayed by GBLSEC$SDA and by the SDA commands, so I'm not sure, if you are really looking at the same data at the same time...

GSTX: 00000341 .ne. SDA> show gst/section=163
GSD: A8F53820 .ne. A8F66340
etc.

Once you have obtained the correct GSTX, you can also use SDA to search for pages mapped to this global section for all processes in the system:

SDA> SHOW PROCESS/PAGE/GSTX= ALL

This should work, even if the channel to the section file has been closed.

Volker.

[Bernado Pehar_1]

Hi Volker,

well observed, the data is different, but this is due to the fact that I ran the examples on 2 different days, where the sections had already been recreated. Nevertheless, your last SDA command was the solution: It lists all processes attached to the section, exactly what I was looking for !!! In combination with the GBLSEC Extension from Ian Miller this is all I need ;-)

Thanks a lot for the hint !

Regards,

Bernado

[Ian Miller.]

If
SDA> SHOW PROCESS/PAGE/GSTX= ALL
finds processes and GBLSEC$SDA does not then I have some work to do :-)

[Bernado Pehar_1]

Hi Ian,

that would be a nice thing to have, since the GBLSEC tool is really neat and would save the work of having to send the output to a file and search it for the information ( since there can be quite a lot of output from the SDA Commands on the terminal ).

Regards,

Bernado