"Sorry, cannot connect to Calendar Server"

[Transpower]

This annoying message comes up in my new 5.0.7 OpenServer installation. In the
past I would just type from root, isverify -I. That would fix the problem.
Not in this case. Is there something else I have to do?

Regards,
RWS
[email]transpower@aol.com[/email]

[Bela Lubkin]

Transpower wrote:

> This annoying message comes up in my new 5.0.7 OpenServer installation. In the
> past I would just type from root, isverify -I. That would fix the problem.
> Not in this case. Is there something else I have to do?

Are you using the calendar service? If not, your best bet is to disable
it: edit /etc/rc2.d/P95calserver, add a line that says "exit 0" to the
top of the script.

If you _are_ using the calendar service, then when does this message
come up? During boot? When you try to use the calendar client?

>Bela<

[Transpower]

Bela:

.... when I click on on the Calendar icon in the X-desktop.

RWS
[email]transpower@aol.com[/email]

[Bela Lubkin]

Transpower wrote:

> ... when I click on on the Calendar icon in the X-desktop.

I'm sorry, I only half remember the context of this discussion. Please
use a new posting program which is able to quote context, and _do so_.

>Bela<

[Transpower]

Bela:

Subject: Re: "Sorry, cannot connect to Calendar Server"

> This annoying message comes up in my new 5.0.7 OpenServer installation. In

the

> past I would just type from root, isverify -I. That would fix the problem.
> Not in this case. Is there something else I have to do?

I am using the Calendar Service. The error message occurs when I double click
on the Calendar Client icon on the X-windows desk top. There is a "Fatal
Error" of the Calendar Server during boot.

RWS
[email]transpower@aol.com[/email]

[Bob Bailin]

"Transpower" <transpower@aol.com> wrote in message
news:20030804101620.13162.00001245@mb-m10.aol.com...

>

> > This annoying message comes up in my new 5.0.7 OpenServer installation.

In

> the

> > past I would just type from root, isverify -I. That would fix the

problem.

> > Not in this case. Is there something else I have to do?

>
> I am using the Calendar Service. The error message occurs when I double

click

> on the Calendar Client icon on the X-windows desk top. There is a "Fatal
> Error" of the Calendar Server during boot.

Go to /etc/rc2.d/messages and show us the entire contents of
P95calserver.log
Do not paraphrase the contents.

Bob

[Transpower]

>Go to /etc/rc2.d/messages and show us the entire contents of

>P95calserver.log
>Do not paraphrase the contents.

Bob, JP, as requested:

"FATAL ERROR: se '/usr/lib/sco/oadb/caldata/calsrvlog'"

The contents of calsrvlog:

Server ID: port = 6373
machine = non-networked
servers = 1
startup date: 08/04/03
startup time: 17:23:27

Server is executing ....

ERRNO = 22, T_ERRNO = 0, ISERRNO = 117
unable to open '/usr/lib/sco/oadb/caldata/event' database files
DATE: 08/04/03 TIME: 17:23:27

Server is exiting! Goodbye!

------

How's that for specificity?

RWS
[email]transpower@aol.com[/email]

[Bela Lubkin]

Transpower wrote:

> "FATAL ERROR: se '/usr/lib/sco/oadb/caldata/calsrvlog'"
>
> The contents of calsrvlog:
>
> Server ID: port = 6373
> machine = non-networked
> servers = 1
> startup date: 08/04/03
> startup time: 17:23:27
>
> Server is executing ....
>
> ERRNO = 22, T_ERRNO = 0, ISERRNO = 117
> unable to open '/usr/lib/sco/oadb/caldata/event' database files
> DATE: 08/04/03 TIME: 17:23:27
>
> Server is exiting! Goodbye!

Ok, now we're getting somewhere. In order for this to have succeeded,
the directory /usr/lib/sco/oadb/caldata has to exist, and it has to
contain files named event.dat and event.idx. Does it? We can guess
that the directory exists since you've shown us the contents of
calsrvlog from the same directory. Now show us the permissions of the
involved files:

# ls -ld /usr/lib/sco/oadb/caldata
# ls -l /usr/lib/sco/oadb/caldata

But wait... this is probably your issue. See:

[url]http://stage.caldera.com/cgi-bin/ssl_reference?105237[/url]

>Bela<

[Bob Bailin]

"Transpower" <transpower@aol.com> wrote in message
news:20030805182754.28365.00000043@mb-m10.aol.com...

> Bob:
>

> >Either you installed your system on July 29th, or you
> >tried to set a calendar event at that time and something
> >got munged up. I suspect the former, and I also suspect
> >you may have discovered one of those unpleasant side-
> >effects of upgrading a system rather than doing a
> >fresh install.

>
> I installed the system on July 29. I did not try to set up a calendar

event.

> I simply tried to access the calendar client.

This is probably a language related issue.

Look in /usr/adm/ISL/iqm_file for the line: IQM_LANGUAGE=
(easy to find, they're all alphabetical and all start with "IQM_")

What language is shown? The default is "C_C.C".

Now look in the file /etc/default/lang for the first two non-comment lines.
They should both be LANG=C_C.C

If either of these are not the case on your system,
you were a little too clever for your own good when installing
5.0.7 (or the previous version you upgraded from) and
selected another, seemingly reasonable language choice
such as "english_us.ascii". Unfortunately, this reasonable
choice breaks a few scripts & programs such as the
calendar server, as I found out myself years ago when
first installing 5.0.2 or 5.0.4.

Bob

[Transpower]

Bob:

>Look in /usr/adm/ISL/iqm_file for the line: IQM_LANGUAGE=
>(easy to find, they're all alphabetical and all start with "IQM_")
>
>What language is shown? The default is "C_C.C".

There was no language specified, so I added the default just now.

>
>Now look in the file /etc/default/lang for the first two non-comment lines.
>They should both be LANG=C_C.C

No, one wasn't so I changed it to the above.

>
>If either of these are not the case on your system,
>you were a little too clever for your own good when installing
>5.0.7 (or the previous version you upgraded from) and
>selected another, seemingly reasonable language choice
>such as "english_us.ascii". Unfortunately, this reasonable
>choice breaks a few scripts & programs such as the
>calendar server, as I found out myself years ago when
>first installing 5.0.2 or 5.0.4.

Alas, making these changes did not solve the problem. I still get the error
message "Sorry, cannot connect to Calendar Server". The bootup error message
is the same as previously posted.

RWS
[email]transpower@aol.com[/email]

[Bob Bailin]

"Transpower" <transpower@aol.com> wrote in message
news:20030806181505.21977.00000064@mb-m07.aol.com...

> Bob:
>

> >Look in /usr/adm/ISL/iqm_file for the line: IQM_LANGUAGE=
> >(easy to find, they're all alphabetical and all start with "IQM_")
> >
> >What language is shown? The default is "C_C.C".

>
> There was no language specified, so I added the default just now.

The iqm_file is simply a list of the answers you provided during
installation of 5.0.7. During a fresh installation, one of the questions
you must answer is which language the system will be using.

Since you did an upgrade, I guess it never asked you and continued
to use the same language as the prior edition, whatever that was.

> >
> >Now look in the file /etc/default/lang for the first two non-comment

lines.

> >They should both be LANG=C_C.C

>
> No, one wasn't so I changed it to the above.

> >
> >If either of these are not the case on your system,
> >you were a little too clever for your own good when installing
> >5.0.7 (or the previous version you upgraded from) and
> >selected another, seemingly reasonable language choice
> >such as "english_us.ascii". Unfortunately, this reasonable
> >choice breaks a few scripts & programs such as the
> >calendar server, as I found out myself years ago when
> >first installing 5.0.2 or 5.0.4.

>
> Alas, making these changes did not solve the problem. I still get the

error

> message "Sorry, cannot connect to Calendar Server". The bootup error

message

> is the same as previously posted.

I think it's time to realize that the upgrade was not an appropriate
option for you. Eat your losses and start again with a fresh
install of 5.0.7. If you have other filesystems besides root, you
can preserve them during the fresh install.

I'll assume you still have a complete, verified backup of 5.0.4 from
July 28th. Keep it handy (and write-protected) for future reference.

Bob

[Transpower]

>Eat your losses and start again with a fresh

>install of 5.0.7.

Bob, Bela:

I'm not willing to give up. It's a learning experience to figure out the
solutions to such problems. Is there a way to uninstall and then reinstall the
calendar files using custom or customextract?

RWS
[email]transpower@aol.com[/email]

[tony@aplawrence.com]

Transpower <transpower@aol.com> wrote:

>>Is there a way to uninstall and then reinstall the
>>calendar files using custom or customextract?

>I did just that! I removed the calendar and calendar server (using Software
>Manager) and then I installed the calendar and calendar server from the master
>SCO CD. Voila, the calendar now works!

Which would indicate that the reason it did not work previously was due to the IPU
retaining something it should not have or otherwise screwing up.

IPU's are more time consuming than they appear.

I hope some folks are learning something from this.

--
[email]tony@aplawrence.com[/email] Unix/Linux/Mac OS X resources: [url]http://aplawrence.com[/url]
Get paid for writing about tech: [url]http://aplawrence.com/publish.html[/url]

[Transpower]

Tony:>Which would indicate that the reason it did not work previously was due
to

>the IPU
>retaining something it should not have or otherwise screwing up.
>

....which indicates to me that SCO should do a better job in implementing
in-place upgrades. It's not the user's fault.

RWS
[email]transpower@aol.com[/email]

[tony@aplawrence.com]

Transpower <transpower@aol.com> wrote:

>Tony:>Which would indicate that the reason it did not work previously was due
>to

>>the IPU
>>retaining something it should not have or otherwise screwing up.
>>

>...which indicates to me that SCO should do a better job in implementing
>in-place upgrades. It's not the user's fault.

???

Of course it's not the user's fault.

I contend that no amount of engineering foresight can account for every
possible screwup on an IPU.

If, however, IPU's documented their work as I have suggested at
[url]http://aplawrence.com/Unixart/ipuvsfreshinstall.html[/url] , I'd be much
more favorable toward this approach.

--
[email]tony@aplawrence.com[/email] Unix/Linux/Mac OS X resources: [url]http://aplawrence.com[/url]
Get paid for writing about tech: [url]http://aplawrence.com/publish.html[/url]

[Bela Lubkin]

[email]tony@aplawrence.com[/email] wrote:

> Transpower <transpower@aol.com> wrote:

> >Tony:>Which would indicate that the reason it did not work previously was due
> >to

> >>the IPU
> >>retaining something it should not have or otherwise screwing up.
> >>

>

> >...which indicates to me that SCO should do a better job in implementing
> >in-place upgrades. It's not the user's fault.

>
> ???
>
> Of course it's not the user's fault.
>
> I contend that no amount of engineering foresight can account for every
> possible screwup on an IPU.
>
> If, however, IPU's documented their work as I have suggested at
> [url]http://aplawrence.com/Unixart/ipuvsfreshinstall.html[/url] , I'd be much
> more favorable toward this approach.

And I've said that they do, or close enough for your purposes.

Now that Transpower has removed and reinstalled his calendar subsystem,
it's probably too late; if he had a backup of it from before the R&R, he
could compare it to the current install and probably figure out exactly
what was wrong.

He now has a fresh, unconfigured calendar server. If he had previously
configured it then that configuration would now be lost, and he would be
scrambling to find it (and 100 other things lost during a fresh
install). Both routes involve a lot of subtleties.

>Bela<