I have a config on SCO OS 5.07 with 2x120gig disks.

The pick0 disk line is described in the raining data docs as having the disk
line
# disk /dev/rpick0 offset sizein1kblocks # disk 0
disk /dev/rpick0 0 2097152 # disk 0

The manual talks about the first int after the disk device as the "Offset" .
Would this then be similar to a divvy table?

What's the most disk space you can configure for D3 on SCO OS 5.0.7?

If I wanted to configure more than 30gig, of hd space for D3 what would be
the best method - is there?



Thanks for any help

The standard D3 install technique is to use a pick0 disk statement
(max 2GB) that points to a raw partition, or in the case of SCO, a
division (aka divvy?). Since SCO limits you to 4 partitions per disk,
and 7 divisions within each partition, you are limited to a maximum of
4x7=28 divisions, x 2GB = 56GB max per disk available for D3. (This
assumes that none of the divisions are used for unix filesystems or
swap space.) There are two work-arounds:

1. As you mentioned, the pick0 disk statement includes an "offset"
parameter. I used the offset parameter successfully in D3 7.0 to
address a large division in multiple disk statements, but I don't
think it works any longer in releases since 7.0 (i.e. the only valid
offset is 0). This leaves option 2...

2. Run your pick data out of unix filespace, instead of a raw
partition. This is what I did for many years after upgrading a SCO
system to 7.1. What you want to do is create a large division with all
the remaining disk space that you want to dedicate to D3. Then create
a filesystem on that space. Then use dd to create as many 2GB null
files as will fit in the space. I put mine in a /pickfiles filesystem,
and named each file pickfile1, pickfile2, etc. up to pickfile39. I
think SCO filesystems may freak out if they run out of space totally,
so I would suggest leaving about 5% or so of the filesystem
un-allocated. Then reference these individual 2GB files in your pick0
disk statements. I think D3/SCO allows up to either 64 or 128 disk
statements total, so you should be able to access at least 128GB of
disk, or maybe even the full 240GB. You will probably also want to
set the permissions on these "pickfileN" files to 600, so that only
the D3 vm has read/write permission. This concept (running D3 out of
unix filespace) has been touched on several times over the past few
years in CDP, check for posts by Doug Dumitru in particular for more
information.

The real answer, however, is to change to linux. The SCO/D3 release is
now quite old (as is SCO OpenServer 5.07 itself!). I'll bet
RainingData will upgrade you to linux for free (assuming you have a
maint contract). Linux/D3 (as of 7.2.1) does not have the same disk
limitations, however it does have a problem with overflow handling and
with update-prot. These are supposedly fixed in 7.4; I am installing
that this week and will find for myself soon.

--
Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831



cracboy wrote:

"cracboy" wrote
SKIP
at the front end. Is like doing a dd command with a seek= clause.
Use 0.
You'd expect minimal SCO disk usage compared to D3, so how about putting
in two disk lines that use somthing off each of the two disks, for speed?
Older D3/sco had a 2gigabyte per 'disk' statement limit. Yours probably
doesn't.
Remember you can easily add more disk statements later {put 'em AFTER
these!}
The space from the new disk stmts will show up when next you start D3 up.

Have tried a variety of methods and, for a production machine, I lack
confidence in the settings.
Has anyone set the disk lines up that can give me an example of internal
disk syntax for the pick0?

so far I lean towards the following

disk /dev/rpick0 0 2097152 # disk 0
disk /dev/rpick0 0 2097152 # disk 1
disk /dev/rpick0 0 2097152 # disk 2
disk /dev/rpick0 0 2097152 # disk 3
disk /dev/rpick0 0 2097152 # disk 4

what would be the statements for an internal disk file using the dd method?

thanks again



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

Here is a post by Doug Dumitru in Nov 2002 that should get you started
(the SCO dd syntax may be slightly different):

[snip]
I think this part is in error... should be:
disk /u2/d3-dsks/1 0 2000000 # disk 0
disk /u2/d3-dsks/2 0 2000000 # disk 0
disk /u2/d3-dsks/3 0 2000000 # disk 0

cracboy wrote:
--
Scott Ballinger
Pareto Corporation
Edmonds WA USA
425-670-0831

"cracboy" wrote
ten gig partition then ok, but make the offset column be
0 on #disk 0,
2097152 on #disk1,
4194304 on #disk2, etc. That would be the 'dd' way...
Side note; won't hurt if you are conservative and declared 2097152 on a
divvy/partition that was in fact bigger than that, say 2200000 kbytes large.
Won't hurt if you make your offset numbers bigger
than they have to be to avoid overlapping '#disk n'
statements; disk /dev/foo 0 2097152 # first chunk
disk /dev/foo 2100000 2097152 # 2nd chunk
would just fail to use (2100000-2097152 + 1) kbytes of foo's room
between the two chunks declared.

More typically you'd leave offset at zero and supply different /dev/ names
for each line, but in your case I understand that sco wouldn't be able to
fdisk/divvy your huge hard disks fully, so enough such names aren't
available.

I too encourage you to switch to d3/linux; relinking the sco kernel for
trivial system config changes, fighting quirks of their 'easy' scoadmin
screens got _really_ old for me back in our OpenServer 5.0.6 days...

"Frank Winans" wrote

Thanks guys

Have the following in my 7.1 d3 pick00 file
disk /pick1/1 0 2000000 # disk 0
disk/pick1/2 0 2000000 # disk 1 ..........

appears to work
but I get an error No disk has been defined.

see new posting if you can help on that one.
Ta
Chris

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

Fixed the no disk error,

had to use the full path when starting the d3 vm;

d3 -0 -n /usr/lib/pick/pick0 -a x

ta

"cracboy" wrote
from your current directory. Second choice is
/usr/lib/pick/pick0