Db_Vista database error -924 and another question

I had not heard that unique process names are less risk to shared memory.

I’ll be interested to know if that is the case becuase with that in mind a strategy in my case could be easily implemented going forward.

Consequently, we haven’t made any effort to make process names unique.

I checked and by chance we have 10 process names that are not unique in prodcution across different sites.

I have never observed a shared memory issue serious enough to cause any prodcution down time in my 9 years of service at MD Anderson.

I do occasionaly get shared memory descrepancies to show up when running the don_check_shmem.ksh script you will see later on.

I run this script to help make me aware of how much risk my shared memory might have.

What I like to see are no discrepanices and just the site names listed when the script is run.

The more descrepancies I have the more nervous I become and try to resolve them when I get too uncomfortable.

Unfortunately, the discrepancies have been challenging to get rid of and I have to do a hcisiteinit and recreate the site to make them go away for good most of the time.

I have found out that creating a homegrown set of standard operating procedures for how to make certain changes and migrating interface into prodcution keeps the discrepancies under control.

When we deviate from our home grown known working standard operating procedures is when we have noticed more descrepanices.

I also have a growing suspicion that editing the NetConfig directly instead of using the IDE can contribute to the risk of shared memory discrepancies.

Yes we all know it is a bad idea to edit the NetConfig directly for many other reasons but some individuals persist anyway, even I’ve been known to get lazy and do it, please forgive me for I have sinned.

Here is the main KSH script given to us by Don Ramey if you want to run it and see just how many descrepancies show up.

don_check_shmem.ksh

#########################################################################
# This script checks to see if the list of threads in shared memory
# matches what is in the NetConfig
#
#———
# History:
#———
#
# 2004.10.17 Russ Ross
# [code]#########################################################################
# This script checks to see if the list of threads in shared memory
# matches what is in the NetConfig
#
#

Yes I have received this error.  It was a tough one to figure out, even with the help of the Quovadx technicians.  It was caused because one of the threads I built had a long thread name.

Every time I started the thread, the entire engine would crash.

I minimized the number of characters in the thread name and the problem dissapeared.  This can happen with thread names and process names.  Recommended that thread name be no more than 15 characters long, process names no longer than 9.

Dan Loch

I haven’t had a problem with non-unique process names.  I have had a problem with copying and pasting threads from a network configurator on one site to another.

I have not seen this error “yet” and we do not have uinque process names.  My test environments are copies of prod.  I have had as many as 3 test sites on the same box all with the same process names and have not had a problem.

I am running around the office knocking on wood right at the moment.

Some are saying they have seen duplicate names cause problems and others have not had problems.  Others indicate long names cause problems while others have not had issue.  Thought I would help clear that part up.

Depending on the OS you will either get a separate shared memory for each site or one shared memory used by all sites.  No control over that for cloverleaf.  The ones who are on an OS with one shared memory (windows and a couple unix versions) have more risk of conflicts between sites.  Thus some of you have seen this and some have not.  My recommendation is to not have duplicate names across sites and then you are safe regardless of OS.  You might be on an OS that is safe today but have the big whigs upstairs decree you switch to a different one next year.  Might as well be set up where you are safe regardless.  That is just my philosophy though.

The process and threadname length issue was found through a lot of experimentation by one of our support analysts.  The exact length causing a problem varied by OS and was intermittent when encountered.  Thus one person might have found one number to be a problem while those in  a different environment saw something different.

If I remember right 26 or below was safe for all.  I usually recommend staying at 26 or below when combining site+process+thread so I am safe regardless of OS.  That way I do not have to remember exactly what number was a problem with each OS and if you have to migrate to a different OS in the future you are not at risk.  Why do something that could cause a problem some day?  That is just the defensive programming I was taught in college.