David M Kerr

Now that you know where your object is located. You probably need some more information about it.

Before we saw that the object for my item master oitm0101 was located here:

/apps/baan/bse/application/tiB40U_c4_stnd/otiitm/oitm0101

Now if we want some info we can use one of three commands

what /apps/baan/bse/application/tiB40U_c4_stnd/otiitm/oitm0101
- or (if you're fancy) -
what `explode6.1 otiitm0101`
- or -
bic_info6.1 -w oitm0101

You can use bic_info.exe for Windows.

Both will give the result below:

---------------------------OBJECT IDENTS--------------------------------
@(#)/b40c/bse/application/tiB40_c5/ptiitm/pitm0101g, 04/11/16 [20:34], From wtreur
@(#)-DREL6_1
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_global@@/main/bugfixB40c6/developmentB40c7/10
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_object@@/main/bugfixB40c6/developmentB40c7/2
@(#)4GLE_BUILD_BaanIVc7_1184 -- bic_event@@/main/bugfixB40c6/developmentB40c7/1
[....]

Here you can see the compile date of the object, this is critical with dealing with Baan support as they can usually map that object info to a defect or solution number assuming it's a standard object.

dbgobj is one of the best bshell debugging options you have available to track down a problem.

It will give you the actual path to an object: this is essential if you have multiple VRCs to find out the VRC that the bshell is using (not always what you expect, and not always the same as explode6.x)

To execute this trace you add -dbgobj to your bshell. it's best to add two other debugging commands to your bshell so you can specify your logfile:
-keeplog and -logfile

In Unix that would look like

ba6.1 -- -dbgobj -keeplog -logfile /tmp/bshell.log

In Windows you add it to the command line

Command: -- -dbgobj -keeplog -logfile c:\bshell.log

The output file will look like this:

---------------------------OBJECT HEADER--------------------------------
B:0000005:::(00001):Object      = otiitm0101
B:0000006:::(00001):Pathname    = /apps/baan/bse/application/tiB40U_c4_stnd/otiitm/oitm0101
B:0000007:::(00001):Magic               = [_bic_dll_]
B:0000008:::(00001):relno               = 61
B:0000009:::(00001):obj_revision        = 1
B:0000010:::(00001):object_flags        = 10

The key to look at is the path to the object. you can see here that I've got object otiitm0101 Installed in tiB40U_c4_stnd which is my standard update VRC for PMC. So we know that I haven't customized my item master (thank goodness)

If you create a new database, listener, etc. on a machine that has an existing Grid Control Agent on it, you may need to tell the agent to “rescan” the system to pick up the new database (to have the DB show up in OEM).

Set your agent home

AGENT_HOME=/opt/app/oracle/agent10g

Make sure $AGENT_HOME/bin is in your PATH
Run the agentca with the reconfigure option. (you may need to specify a –c for RACs)

vexbert<11> agentca -h
Usage: agentca -d/-f [-nctis]
        -d  option for rediscovery.
        -f  option for reconfigure.
        -n  to specify the CLUSTER_NAME.
        -c  specify the list of cluster nodes separated by commas
        -t  don't start the agent after rediscover or reconfigure.
        -i  oraInst.loc location on Unix/Linux Platforms only.
        -s secure the Agent during RAC/Cluster Agent reconfiguration
         (Don't use this option in upgraded home).

vexbert<11> agentca –f

Note: you may need to clean up duplicates in your OEM after running this on an existing system.

I once ran into an instance where the Unix admins didn't believe me that i was running out of shared memory despite the errors, I was showing them. I wrote this perl script to allocate chunks of shared memory until it failed to prove to them that yes, regardless of what you have the global ulimits set to my user's limits were lower.

#!/usr/bin/perl -w

use IPC::SysV qw(IPC_PRIVATE IPC_RMID S_IRWXU);

$size = 50000000;
$id = shmget(IPC_PRIVATE, $size, S_IRWXU) || die "$!";
sleep 10;
shmctl($id, IPC_RMID, 0)

Sometimes you may see core dumps, etc related to lack of shared memory.
To check to see how much is currently being used you can use the below command:

vexbert<10> ipcs -bm
IPC status from  as of Thu Oct 30 10:42:06 PDT 2008
T         ID      KEY        MODE        OWNER    GROUP      SEGSZ
Shared Memory:
m 1493172237   0x32d14fb8 --rw-r-----   oracle      dba 2097160192
m 1979711547   0x5e000b64 --rw-------     root     root        512
m  721420366   0xe867eba0 --rw-r-----   oracle      dba 2147491840
m         25   0x67e97344 --rw-r-----   oracle      dba  419438592
m         21   0xc4986724 --rw-rw----   oracle      dba  629153792
m         19   0x71e930c0 --rw-rw----   oracle      dba 1073758208
m          7   0x4154520e --rw-rw-rw-     root   tivoli    1048576
m          6   0x4154520a --rw-rw-rw-   tivoli   tivoli    1048576
m          5   0x4154520d --rw-rw-rw-   tivoli   tivoli    1048576
m          4   0x4154520c --rw-rw-rw-   tivoli   tivoli    1048576
m          3   0x4154520f --rw-rw-rw-   tivoli   tivoli    1048576
m          2   0x4154520b --rw-rw-rw-   tivoli   tivoli     524288
m          1   0x41545200 --rw-rw-rw-   tivoli   tivoli    1048576
m          0   0          --rw-------     root     root         64

The Oracle/DBA segments are related to Oracle database instances.
The SEGSZ is limited by the Unix kernel.