Hello,

I am an (old) developer, and have a user who runs my systems on a PC
using Windows 2000. The D3 is "the one and only FSI MDS server", so
there can be only one user.

The first problem is the length of time that D3 takes to shutdown, in
excess of twenty minutes. I shutdown using D3-Tray. Is there anything
I can do to speed up the shutdown? I have a mirror of the system at
home but using Windows XP which shutsdown in less than a minute.

The second problem is if the shutdown is not allowed to finish (at
least I think that is the reason) then on the next start up we are not
allowed access because a "Too many users" message appears. The system
will not then shut down and D3-Tray flashes for ever. Is there a way
of getting rid of the signed on user?

My systems have run for years without much intervention, and the latest
trouble was instigated by a request to change the "Computer Name". I
changed it on the mirror system and it appeared to make no difference
to D3. Is anything in D3 affected by changing the Computer name?

That's three questions ABS inconsistancy sorry.

Thanks for any help,

All the best,

Chris Potts

So, you change the name of your "one and only" MDS server computer ....
was this reflected with a change to the D3 config? (nor sure if this is
necessary)


chrisjpotts wrote:

A couple of questions/observations back at you:

1) How many "users" on the system, and how many pibs. When you shutdown,
the system has to wrap up all the pibs. If you have 10 users but 256 pibs,
it takes a while to shutdown. Try reducing the number of pibs to users +
phantoms + a couple extra.

2) If the system does not shutdown cleanly, it probably does not restart
cleanly. Also, as I recall, there's a registry parameter that controls if
the system boots up in single user mode or not. Check that and make sure
it's set to M for multiple user.

3) If you change the name of the computer but not the name of the Pick
Virtual Machine, D3 may have a problem locating the system. Just use D3
DeviceMangler and make sure the virtual machine name matches what you called
the server.


Mark Brown


"chrisjpotts" <chrisjpotts (AT) orobanche (DOT) co.uk> wrote

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote:

*GACK* Mark, that's only half the info! Changing those numbers
without the following info will result in an unusable system.

This is something I know a lot of VARs don't do...

Chris, you need to get a full file-save of the system. Be sure that
the MDS q-pointers for the FSI are QS pointers so that they are
actually saved, and any DX/DY files are saved if you really want them.

In the D3 Device Manager D3 NT Settings, you can change the PIBS and
phantoms to both be something like 12. (You get 12 free phantoms with
D3, you might as well keep um.) That gives the system a total of 24
processes to shutdown instead of 266 and the boot/shutdown will go
much faster.

Now you need to restore the system from the save. Reason: Just like
in the old days (except for Microdata bless their hearts), the PIBs
are configured at the front of the system and all files come after
that. Shift the end of the PIBs down and all of the files need to
shift down too.

To avoid the restore you can change the default PIB/phantom ratio from
256/10 to 10/256. That will keep the count the same. Mark - if
phantoms are not used, do they go through some kind of instant wrapup?
I know the guys spent a lot of time on this code to optimize the
process. If this is the case then you can reset to 10/256 or 20/246,
etc, just keep the total number the same, and the system will shutdown
very quickly.



That's not what that setting means. D3 is designed to be run in a
distributed environment, with accounts spread across the network.
Yeah, hardly anyone uses it like that. The idea is that, for example,
you can have a user maintaining data that is stored on their own local
PC, or you can put development data on a development server and
production data on a production server - rather than putting all data
all on one box as in a conventional MV environment.


That's a flag right there. Why would the shutdown not be allowed to
finish? Someone cancelling the shutdown? D3Tray intercepts the
Windows shutdown, takes down D3, then continues the Windows shutdown.
It hasn't been updated in years and probably may not do exactly what
it should, but in any case it shouldn't be interrupted when it's
shutting down D3.

D3Tray was written many years ago by Pierre Trinephi and offered as
freeware. Then RD decided to bundle it with D3. I don't think anyone
at RD knows what's in that code, it's certainly not maintained. If it
works for you, great, if it doesn't just recognize that it's not a
full component of D3 as are other components, and if you need
something more or different then you'll have to look elsewhere.


That's a separate topic which Mark addressed - shouldn't be related to
the shutdown.

HTH
Tony Gravagno, Nebula Research and Development
TG@ always.remove.this.partNebula-RnD.com

Hi Tony
I am horrified at the suggestion that changing the number of pibs in the D3
device manager will wreck the system without a restore. I have never seen
anything in a manual about that and it would certainly be a suable
situation.
I have always reduced the number of pibs without problem to speed up
shutdown.
Have I missed something and just been lucky?
Peter McMurray
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

I believe you can reduce the pib count without worry, but in order to go up,
the blob needs to increase in size, requiring a save/restore.

Mark'll confirm/deny this.

Ed

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

Get A Clue, Kid?

(Can't imagine _any_ of the definitions on urbandictionary
dot com are the one you mean.)

--
frosty

I believe Peter is right and I was probably wrong - but I'm not going
to test the theory on my own system. Upsizing past the base FID will
definitely require a restore. I don't believe RD documents this in
normal ref material for D3NT. The RD NT FAQ however does include a
note about upsizing and says clearly that you need to restore if
you're upsizing. The Device Manager also doesn't let you upsize PIBS
unless you check a box. surprisingly it _does_ let you upsize
phantoms without any warning or override control. Duh... Through
inferrence one can conclude that you don't need to restore if you're
downsizing, but I would neither depend on that sort of interpretation,
nor would I sue anyone based on it.

For D3NT, downsizing doesn't touch the pointers that have already been
written into the VME - so you should be able to get away without a
restore. For all other D3 platforms, unless something has changed
that I don't know about, the base FID is calculated based on the
number of ports used for booting - change the number of ports and the
system won't know where to look for the mds, that means you can't
boot, and that's why you need a restore. Again, they may have changed
this for *nix so that the system at least checks for a file system at
a stored location before calculating it. I don't much care about such
things anymore.

Get a good save in any case.

BTW to Frosty: GACK wasn't intended to be an acronym, I was choking on
my coffee.

T

when the system gets laid out during restore, the abs go in first, then the
pibs, then the "system" file.

If you are adding users, the new users pibs will be laid right over the top
of your system file, rendering the system useless.

Downsizing has no such problem because everything that needs to be there is
still there. You just have a few (hundred, potentially) lost frames between
the last PIB and the first frame of MDS.

Mark


"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Thank you all for the warnings. I have never upsized without doing a
release update as well so I have been lucky as I would definitely have been
caught.
Peter McMurray
"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote