I was wanting to do some file resizing at a client site, but I thought
I'd better check with CDP for the best method. These are all FSI
accounts, and I know about NTLFS and FSIM,File-Of-Files,. What eludes
me is the best technique for doing a bulk resize of files in an account.

There are programs such as nt_resize and nt_resize-menu that will do one
file at a time, but I'd really like to see something that can calculate
recommended file size across an account and then apply them, either by
populating attribute 13 of the D-pointer or by making the necessary
calls to do it in place.

At least one of these files will be very large (1.5 million groups), so
I'm not sure what the effect might be of trying to resize it on the fly.
For that matter, even resizing via a save/restore is likely to be
prohibitive.

Any thoughts?

TIA,
Luke

Luke,

What flavor of Pick are we talking about?
I have a piece of software that will run on Generic Pick flavors and
populates attr 13 of D-pointers. It will do the whole system if you so
wish or a list of accounts.
It was written for the need of such a utility that wasn't available
years back but its still serving us today. We do all our resizing using
it.

Now here's the best bit.
We're just around the corner from where you live. Why don't you come
and visit us at Interactive Data in Malvern, see jak and we'll take it
from there.

regards
jak

see the subject line
<iakovos (AT) gmail (DOT) com> wrote

Luke,

We have a process that we typically tie in after our backup routine
which allows us to specify when to stop resizing, and also a "bad size"
parameter that we will accept before we do a resize (some files I'm
happy to be undersized by 2-300% ... with knowledge of the data usage)

Anyway, if you don't have something in place already (our code base
goes back 20 years for this!), start with dm,bp, f-resize .... you now
have 2 routes to travel :

* rather than writing <13>, do an online resize, & before you go onto
next file, see if we are after the "stop time" .... If so exit
routine (ready for next night) otherwise process next file

OR

* fire 2 phantoms ... one does work as above, other one sleeps until
"don't resize any more 'cause users will be coming in" time,
then does a kill-resizing. If you use this technique, check dm,resizing
on start so you can kick off resize of any file that was part way
through last time

Either way, I imagine you don't want to impact online users ... if
you are talking modulo 1.5m+ then the system is busy enough !

You can fine tune this process to have multiple resize phantoms, but
have to judge if there is any REAL speed advantage because of resource
contention. You could also keep your own stats on "shaping" based
on times taken to add "X" frames to a file with "Y"
bytes/record.

Of course there will be some "pain" on your first resize cycle, but
once you are up & running, most files will NOT need to be resized at
the same time - and most of your resizes may run over entire
weekends.

Final notes : don't forget to CLEAR <13> once resized (so you
don't rehash on file restore by accident) - and at least once every
12 months a FULL/REAL restore should be done for optimal performance,
as multiply resized file will have multiple extents. NEVER reduce a
module unless you REALLY know WHY, and even then think again 'cause you
are probably wrong !

HTH

Ross Ferris
Stamina Software
Visage - Better by Design !

Use the FILE-SIZER menu from the DM account.

This allows you to set up a background job which can wake up at a
pre-determined time, check file sizes and re-size as it goes.

We've had this running on several D3NT sites for over two years with
good success.

I was trying to find the documentation on the RD site for you but drew
a blank. Sorry.

Cheers

Graham