We've lived with a problem for years, but I'm
idly curious, how do you guys handle the
lines in /etc/inittab that service each serial port?

They are handy to have in inittab, since they'll
respawn if the user does an EXIT at tcl,
but during bootup those serial ports are unavailable
until the /etc/rc3.d/ script runs that services the
serial port card. So you get, for each line, a
'respawning to rapidly' message on the system
console that warns the line of inittab will be
disabled for five minutes.

Details; one pci/xem card driving just one sixteen
port box. The dgap script loads
the dgap kernel module and also launches
the digidl {digi download} demon. Oddly
enough, the kernel module also gets autoloaded
__very__ early in linux bootup, long before
these rc scripts start launching, but that digidl
demon is needed to make the /dev/ttya??
entries work. A sample inittab entry might be
dg13:345:respawn:/usr/bin/d3 \
-13 -n pick0 -t ttya13 -y 19200

Just a bootup time pesky nuisance, but I've
always wondered if I was 'doing it all wrong'
ever since the ap/sco days...

oops, I had been Googling poorly on this; there's
lots of good advice shown by searching for

"respawning too rapidly" newsgroup:comp.databases.pick


I know there's a -w flag mentioned in the help d3
document page, but I've never gotten it to work, yet never
cared enough to track down why, nor to cobble together
some shell script.

And this also isn't just a bootup situation like I claimed; you'll
get symptoms until you get D3 started, which impacts
sites that prefer to
d3 -0
then
x
manually, long after linux bootup finishes.

I thought issues like this were resolved a decade ago. Dude, if
you're having some chronic issue for more than a week, let alone
months or years, contact the vendor. Sheesh.

"Tony Gravagno" wrote
commands in inittab, they exit since they cannot open the tty device
for about the first minute that linux is booted. This is not really a
fault with d3, since even a linux getty on those tty's would do the same.
And you're telling me that a workaround or solution for that quirk has
been widely accepted for a decade? I guess that's a total 'fail' on my
part, then.

This is distinct from the old old d3/linux where a d3 process would
exit just because the pick vm wasn't up yet. I'm delighted to affirm
modern d3 waits patiently on each line for the vm to come up.

And this is not really a digi international failing, either. They provide
a lovely command ditty that is a sort of enhanced stty for dealing
with their /dev/tty?nn devices, and they clearly rely on a demon
dgapdl that you can look for in the ps -ef output to assure yourself
the dgap script has run since we first came out of single-user mode.
Heck, the thing where unloading and reloading the dgap kernel module
does a linux core dump if your pci/xem board is missing {or more likely
just got unseated on the motherboard while moving the computer in a
careless manner) is entirely preventable by hacking the dgap script
to exit early if lspci doesn't say something something Xem.
{I do fault their dgap script for doing, in two places,
ps -ef | grep -o dgapdl
without noticing that that grep will also return the grep process itself.
I just changed it in both places to instead be
ps -ef | egrep -o 'dga\pdl'
which relies on the invalid escape \p being listed in ps -ef but stripped
down to just p in actual effect.
And I'm not sure if I should blame digi or myself for not noticing the
K15dgap script doesn't actually run since script /etc/rc which handles
that presumes dgap would touch / rm /var/lock/subsys/dgap to reflect
whether or not dgapdl demon was running at the time. No dgap file out
there means dg doesnt' bother to invoke the K15 script to bring down
the presumedly already down dgap subsystem...

I guess I've got sympathy for digi having a customer base dispersed over
_so_ many platforms and releases, many of which probably do not enforce
that /var/lock/subsys thing.

Similarly, D3_setup writes out the config file for maintaining your
/dev/raw/raw? pick partition(s), but in redhat rhel5 the fine folks at
redhat
decided not to run rawdevice scripts to service that config file. The raw
command is provided, and a man page for raw deprecates /dev/raw and
chides software vendors to open files with O_DIRECT instead of
using /dev/raw, but I had to go copy the scripts from
a rhel5.4 installation. I guess D3_setup also issues the raw command,
because you don't notice a problem until you reboot linux, then pick vm
can't
find your raw device.

But I digress. I do make some efforts to Read the Manual, and at least
glance through release notes, and feel annoyed when that doesn't suffice for
even such unexeceptional users as ourselves.

"Frank Winans" wrote:

I understand the distinction you're making between D3 and Linux
(didn't catch that before, sorry). My point was that this used to be
a common question for PS/RD/TL support, and they probably have the
answer over there. What confuses me is how someone can say "We've
lived with a problem for years" without contacting their Support
provider.

My guess is that you're working with an old version of D3 on an old
version of Linux, that the system is no longer covered under Support
by TL nor RedHat, and that you don't have any other upline support
tier. If any of that is not the case, why praytell wouldn't you ask
someone you're paying for such services before you wait for years and
then post a curious issue to a public forum? If that is the case (no
support), well, you're saving some money and dealing with some
aggravation in return. Sure, I hope one of our respected colleagues
can help with the problem. It's just unfortunate that it's been with
you for so long.

The thing that gets me about these situations is that it usually ends
up with someone blaming the MV platform and a subsequent migration -
all because people aren't simply using resources readily available.
How many times have we seen people here citing issues they've had with
D3 for years without contacting the vendor, then they migrate and tell
us all how great the new platform is? Well, yeah, now you're paying
for support and asking the support provider for help. Of course the
new platform is great.

All I'm saying is: give your current vendors a chance to solve
problems before someone begins the initiative to migrate. If they
fail, that's another discussion. This is of course a "way down the
line" jump from a simple forum inquiry, but such migrations usually
begin with "We've lived with a problem for years".

Regards,
T

"Tony Gravagno" wrote

i) diffusion of responsibility; some problems are joint to several firms;
Redhat or Digi International or Tiger Logic each could choose to do
something to make this problem go away, in one way or another,
but that's asking rather a bit much of them -- each of their products is
operating as expected, even if jointly that has an undesired result.

ii) support is _possibly_ handy, but almost certainly disruptive to indulge in;
I only say 'possibly' because they may a) investigate, then fix it later-- much
later. b) admit that is a well-known {to them} problem they're definitely
not going to address until some future release c) give you a certain, or even
just likely, solution that you are then forbidden to implement, such as shift to
a newer release that legacy hardware or software will not tolerate, or just
inconveniences the site involved too far, or exceeds the budget for this
problem d) assert they've never seen that happen.

I say 'disruptive' because we're small fry, and so we only get to call
support during banker's hours. So we may have to disappoint some of
our own customers that expected us to service their support needs
since we're busy talking with the support guru we've contacted. Worst is
when we get a callback from said guru while dealing with a rather impassioned
support call that came in during that wait.

Support will, for a broad range of situations, insist on dialing in to the affected
system. (One might assume that the guru handling my support call had a
similar server he could try things out on, but this is apparently
Not How Things are Done.) Astounding as it may seem, some shops will
reject this request -- explicitly, or by way of assorted complications.

iii) that's not work, that's a hobby
I can work on some things after hours that annoy me, and only me.
That includes unwanted bootup-time messages.
Even if they've annoyed me for a decade.
But I can't ask support for help on them until a client gets ticked off at them, too.

iv) yes, sometimes it is only that the os / d3 is no longer under support that prevents me.
But if I'm seeing a _new_ problem on an out-of-support os / database, the system is
probably old enough that my first hunch is that the programs are fine, but they need to
do some system maintenance, like clearing out the heatsinks or doing a dummy save
or doing a full file restore to recover lost frames or resizing their ever-growing files.

Sadly, some of our clients are so retro that support is no longer _offered_, btw;
not quite as bad as Procomm on a Dos 6.21 box talking to an R83 box,
but bad enough.

So I'll go with a workaround over a tech support call, any day.
But if I suspect it's a problem that absolutely nobody would be willing to pay
extra to know how to fix, I might just see if others feel like reporting on their
own solutions. { I'm unsure if green-screen shops are rare to that degree, yet...}

Add'l to my prior post:
That dgap script does ps -ef | grep dgapdl in two places,
not ps -ef | grep -o dgapdl
When I wrote "... means dg doesn't bother " I meant "...means rc doesn't bother"
The rc script has been enforcing that /var/lock/subsys/* thing since at least redht 7.1
which was kernel 2.4.2, and mid-year 2000. But your S* scripts are guaranteed to
run the first time they're encountered by that bulk clear done by rc.sysinit script.
If it was unclear, I mentioned all that linux-side stuff in a pick forum since you might
want to craft a shell script d3.defer and change d3 to d3.defer in your inittab lines...

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

<snip><
Dude, you really should upgrade to Dos 6.33... _way_ more stable! And if
you're not on Procomm Plus, well, you have no standing to complain...

Ed

You've defined exactly what causes people migrate away from this
market. It's amazing that people get paid a DBMS commission for this
sort of "value-add" service. Holy Toledo.

Tony Gravagno writed:
Nice flame... exactly to whom is this directed? The group?

--
frosty

"Tony Gravagno" wrote
return for keeping that same commission. You might posit that you yourself
could and in fact should be allowed to do a much better job in this arrangement,
once TL had stepped aside, but your position is not be fully informed.

As to us helping migrate market share away, I'm afraid your deep
professionalism has inclined you to mistake a mere coincidence of timing with a
more true cause-and-effect.

And remember my remarks have applied to problems that the _clients_ do not
want fixed -- not beyond the 'gee, I wish it would rain beer' level of sincerity.
In contrast, when their system goes down, or their new printer, doesn't print,
or the major Pick application in question needs maintenance, we follow very
different procedures.

My initial curiosity {see thread title} remains. Further, I presume you were
endorsing Tiger Logic's tech support department, versus Digi International or
Redhat Linux's. You've got me a little worried that I'm forgetting some Admin
Guide or Release Note that addresses this narrow and unlamented problem,
but I'll have to go with a "nope" for now.