I would like to use a larger disk with SIMH than an RA90 (1GB), but
can't dig up any SIMH related info mentioning larger disks.

Can some kind soul please point me in the right direction?

-- 
Paul Sture

In article <paul.nospam-571C2D.17101721112009@pbook.sture.ch>, Paul Sture <paul.nospam@sture.ch> writes:
>I would like to use a larger disk with SIMH than an RA90 (1GB), but
>can't dig up any SIMH related info mentioning larger disks.
>
>Can some kind soul please point me in the right direction?

Assumimg VAX, see the SIMH MicroVAX 3900 documentation section 2.4.2
available at:
http://simh.trailing-edge.com/pdf/all_docs.html

Paul Sture wrote:
> I would like to use a larger disk with SIMH than an RA90 (1GB), but
> can't dig up any SIMH related info mentioning larger disks.
> 
> Can some kind soul please point me in the right direction?

Since you want the "right" direction, you need to turn right and look at:

http://labs.hoffmanlabs.com/node/922

and

http://simh.trailing-edge.com/

Somewhere in there is documentation on the variable to set during
compile so that it allows the use of large files as disk containers.
(Can't seem to find it right now)


And then, in you .ini file, something like

SET RQ0 rauser=3125408
ATTACH RQ0 /Users/jfmezei/dia0.iso

which defines the size of the disk.

On Sat, 21 Nov 2009 17:10:17 +0100, Paul Sture wrote:

> I would like to use a larger disk with SIMH than an RA90 (1GB), but
> can't dig up any SIMH related info mentioning larger disks.
> 
> Can some kind soul please point me in the right direction?

The source code shows RA92 (about 1.4GB).

There's also RAUSER - user defined, up to 2GB on some systems and 1TB on 
those that support such large files.

  SET RQ0 RA92
  SET RQ0 RAUSER=n     (n is megabytes)



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

In article <4b0816e5$0$283$14726298@news.sunsite.dk>,
 burley@Encompasserve.org (Graham Burley) wrote:

> In article <paul.nospam-571C2D.17101721112009@pbook.sture.ch>, Paul Sture 
> <paul.nospam@sture.ch> writes:
> >I would like to use a larger disk with SIMH than an RA90 (1GB), but
> >can't dig up any SIMH related info mentioning larger disks.
> >
> >Can some kind soul please point me in the right direction?
> 
> Assumimg VAX, see the SIMH MicroVAX 3900 documentation section 2.4.2
> available at:
> http://simh.trailing-edge.com/pdf/all_docs.html

Thanks Graham.

-- 
Paul Sture

In article <00c1309c$0$32363$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> Paul Sture wrote:
> > I would like to use a larger disk with SIMH than an RA90 (1GB), but
> > can't dig up any SIMH related info mentioning larger disks.
> > 
> > Can some kind soul please point me in the right direction?
> 
> Since you want the "right" direction, you need to turn right and look at:
> 
> http://labs.hoffmanlabs.com/node/922

Touch� :-)

> and
> 
> http://simh.trailing-edge.com/
> 
> Somewhere in there is documentation on the variable to set during
> compile so that it allows the use of large files as disk containers.
> (Can't seem to find it right now)

I used the "hack" at 

http://labs.hoffmanlabs.com/node/922

to get SIMH to compile with XCode 3.1. Looking at the makefile, it 
appears that the large file support option is already there.
 
> 
> And then, in you .ini file, something like
> 
> SET RQ0 rauser=3125408
> ATTACH RQ0 /Users/jfmezei/dia0.iso
> 
> which defines the size of the disk.

In the latest version of vax_doc.pdf (01-Dec-2008), the "SET -L" line in 
the table of disks at 2.4.2 has unfortunately slipped to the next page:

---- start quote ----
SET RQn RAUSER{=n}  set type to RA82 with n MB's
SET -L RQn RAUSER{=n}  set type to RA82 with n LBN's

The type options can be used only when a unit is not attached to a file.  
RAUSER is a "user specified" disk;  the user can specify the size of the 
disk in either MB (1000000 bytes) or logical block numbers (LBN's, 512 
bytes each).  The minimum size is 5MB; the maximum size is 2GB without 
extended file support, 1TB with  extended file support 
---- end quote ----

There's an area of confusion here in that when you first initialize a 
disk declared using either flavour of RAUSER syntax (under OS X 10.5.8), 
only half of the expected amount is allocated in the host OS. The 
MAXBLOCK size within VMS does look right, and a simple INIT/ERASE will 
expand the container file to the full size.

It strikes me that there's a potential problem here if the host has 
insufficient free space to expand the container to its full size when 
VMS requires it.

Here's an example:

sim> set -L rq3 rauser=10000000
att rq3 /Volumes/simh-data/dua3.dsk
RQ: creating new file

In OS X:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  0 Nov 23 12:58 dua3.dsk

Now do INIT in VMS, and this changes to half the expected size:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  2560665600 Nov 23 12:59 dua3.dsk
$ ls -lh dua3.dsk
-rw-r--r--  1 simh  staff   2.4G Nov 23 12:59 dua3.dsk

Now do INIT/ERASE in VMS and full allocation is achieved:

$ ls -l dua3.dsk
-rw-r--r--  1 simh  staff  5120000000 Nov 23 13:08 dua3.dsk
$ ls -lh dua3.dsk
-rw-r--r--  1 simh  staff   4.8G Nov 23 13:08 dua3.dsk

-- 
Paul Sture

On Mon, 23 Nov 2009 13:54:14 +0100, Paul Sture wrote:

> Now do INIT/ERASE in VMS and full allocation is achieved:
> 
> $ ls -l dua3.dsk
> -rw-r--r--  1 simh  staff  5120000000 Nov 23 13:08 dua3.dsk $ ls -lh
> dua3.dsk
> -rw-r--r--  1 simh  staff   4.8G Nov 23 13:08 dua3.dsk

Does INIT/ERASE write nonzero values to every block? Don't have the 
manual handy.

If not, there will only be enough physical blocks allocated to cover the 
nonzero blocks (on some file systems at least).



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

In article <7mvh5rF3gke5iU40@mid.individual.net>,
 Bob Eager <rde42@spamcop.net> wrote:

> On Mon, 23 Nov 2009 13:54:14 +0100, Paul Sture wrote:
> 
> > Now do INIT/ERASE in VMS and full allocation is achieved:
> > 
> > $ ls -l dua3.dsk
> > -rw-r--r--  1 simh  staff  5120000000 Nov 23 13:08 dua3.dsk $ ls -lh
> > dua3.dsk
> > -rw-r--r--  1 simh  staff   4.8G Nov 23 13:08 dua3.dsk
> 
> Does INIT/ERASE write nonzero values to every block? Don't have the 
> manual handy.

Yes it does. From V7.3 HELP INIT /ERASE

"If you specify the /ERASE qualifier, a DSE operation is performed
on the volume. For disk devices, the ERASE volume attribute is
set. In effect, each file on the volume is erased when it is
deleted."

I note that on V8.3 there are also /ERASE=INIT and /ERASE=DELETE, which 
allow you to specify the DSE operation and the volume attribute 
respectively, /ERSASE=(INIT,DELETE) being the default.

> If not, there will only be enough physical blocks allocated to cover the 
> nonzero blocks (on some file systems at least).

Now you have me wondering if what I am seeing is a feature of the OS X 
file system.

-- 
Paul Sture

Paul Sture wrote:

> Now you have me wondering if what I am seeing is a feature of the OS X 
> file system.


ls -l  provides the file size in terms of number of bytes used. Not sure
which incantation of ls s needed to get allocated blocks.

when you INIT, i believe that by default, it places some of the
structures in the middle of the disk.

So the container file of say 1 gig would have some structure probably
written at the start and its middle, but nothing after. So the file
system would think the logical end of file is the highest byte written,
hence near the middle of the disk.

> ls -l =A0provides the file size in terms of number of bytes used. Not sur=
e
> which incantation of ls s needed to get allocated blocks.
>
> when you INIT, i believe that by default, it places some of the
> structures in the middle of the disk.
>
> So the container file of say 1 gig would have some structure probably
> written at the start and its middle, but nothing after. So the file
> system would think the logical end of file is the highest byte written,
> hence near the middle of the disk.

If you have a simh Vax already running VMS you could use it to pre-
initialize a disk volume (and its underlying Mac OS X disk file) with /
INDEX=3DEND. That would put INDEXF.SYS at the logical end of the disk,
forcing OS X to extend the Mac file to the size you specified in your
simh SET command.

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> Paul Sture wrote:
 
>> Now you have me wondering if what I am seeing is a feature of the OS X 
>> file system.
 
> ls -l  provides the file size in terms of number of bytes used. Not sure
> which incantation of ls s needed to get allocated blocks.

On systems I know, ls -s give the number of allocated (512 byte)
blocks.  If the file has holes, that number can be much lower
than the value from ls -l divided by 512.
 
> when you INIT, i believe that by default, it places some of the
> structures in the middle of the disk.
 
> So the container file of say 1 gig would have some structure probably
> written at the start and its middle, but nothing after. So the file
> system would think the logical end of file is the highest byte written,
> hence near the middle of the disk.

-- glen

On Mon, 23 Nov 2009 08:29:32 -0800, Galen wrote:

>> ls -l  provides the file size in terms of number of bytes used. Not
>> sure which incantation of ls s needed to get allocated blocks.
>>
>> when you INIT, i believe that by default, it places some of the
>> structures in the middle of the disk.
>>
>> So the container file of say 1 gig would have some structure probably
>> written at the start and its middle, but nothing after. So the file
>> system would think the logical end of file is the highest byte written,
>> hence near the middle of the disk.
> 
> If you have a simh Vax already running VMS you could use it to pre-
> initialize a disk volume (and its underlying Mac OS X disk file) with /
> INDEX=END. That would put INDEXF.SYS at the logical end of the disk,
> forcing OS X to extend the Mac file to the size you specified in your
> simh SET command.

Not necessarily. The point is that files on some UNIX file systems are 
allocated sparsely - a block is not allocated to the file until data are 
written to it. One can create (say) a 1GB file, and write the very last 
block to it, only. It then shows up in 'ls' output as a 1GB file. It is 
actually occupying just one block. Any attempt to read the unallocated 
blocks is allowed, and returns a block of zeros.

In VMS terms (if supported!), INDEXF.SYS would have two entries. The 
first would be a 'dummy' one saying that all but one logical blocks were 
unallocated; the second would point to the one 'real' block.

Sounds inefficient, and with ODS-2 etc. it probably would be; it works OK 
on UNIX file systems that were designed for it.

So, to get a properly allocated container file for SIMH, one needs to do 
INIT/ERASE. Seems a good idea, and I think I'll do it from now on.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

In article <00832f91$0$1610$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> Paul Sture wrote:
> 
> > Now you have me wondering if what I am seeing is a feature of the OS X 
> > file system.
> 
> 
> ls -l  provides the file size in terms of number of bytes used. Not sure
> which incantation of ls s needed to get allocated blocks.

ls -s gives the allocated blocks with a blocksize of 512. This can be 
overridden by specifying a different size via the BLOCKSIZE environment 
variable.

ls -sk gives the number of allocated kilobytes, not blocks. This 
overrides the environment variable BLOCKSIZE.


> when you INIT, i believe that by default, it places some of the
> structures in the middle of the disk.

Thanks. That explains what I am seeing.

> So the container file of say 1 gig would have some structure probably
> written at the start and its middle, but nothing after. So the file
> system would think the logical end of file is the highest byte written,
> hence near the middle of the disk.

A test with

set -L rq3 rauser=100000

$ INIT /INDEX=BEGINNING DUA3: DATA_3

$ ls -s dua3.dsk
1056 dua3.dsk
$ ls -sk dua3.dsk
 528 dua3.dsk

$ INIT /INDEX=MIDDLE DUA3: DATA_3

$ ls -s dua3.dsk
51048 dua3.dsk
$ ls -sk dua3.dsk
25524 dua3.dsk

$ INIT /INDEX= END DUA3: DATA_3

$ ls -s dua3.dsk
99992 dua3.dsk
$ ls -sk dua3.dsk
49996 dua3.dsk

Not quite the full allocation, so:

INIT /ERASE DUA3: DATA_3

$ ls -s dua3.dsk
100000 dua3.dsk
$ ls -sk dua3.dsk
 50000 dua3.dsk

Oh, ls -skl also works:

$ ls -skl dua3.dsk
 50000 -rw-r--r--  1 simh  staff  51199488 Nov 24 16:54 dua3.dsk

FWIW doing an INIT /ERASE on a 30GB disk took about 1 hour 10 minutes on 
my 1.5 GHZ PowerBook. I might play with some FDL file placement to speed 
things up here :-)

-- 
Paul Sture

In article 
<6c6ce596-f298-4141-a95d-64b749027dc8@p23g2000vbl.googlegroups.com>,
 Galen <gltackett@gmail.com> wrote:

> > ls -l �provides the file size in terms of number of bytes used. Not sure
> > which incantation of ls s needed to get allocated blocks.
> >
> > when you INIT, i believe that by default, it places some of the
> > structures in the middle of the disk.
> >
> > So the container file of say 1 gig would have some structure probably
> > written at the start and its middle, but nothing after. So the file
> > system would think the logical end of file is the highest byte written,
> > hence near the middle of the disk.
> 
> If you have a simh Vax already running VMS you could use it to pre-
> initialize a disk volume (and its underlying Mac OS X disk file) with /
> INDEX=END. That would put INDEXF.SYS at the logical end of the disk,
> forcing OS X to extend the Mac file to the size you specified in your
> simh SET command.

Once you have created one fully populated volume you can also copy it to 
a new one at the host OS level. It's wise to ensure that SIMH isn't 
using it at the time (either detach the associated unit or exit SIMH 
first to be on the safe side).

-- 
Paul Sture

In article <paul.nospam-BA3995.17084224112009@pbook.sture.ch>, Paul Sture <paul.nospam@sture.ch> writes:
>In article <00832f91$0$1610$c3e8da3@news.astraweb.com>,
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
>> Paul Sture wrote:
>> 
>> > Now you have me wondering if what I am seeing is a feature of the OS X 
>> > file system.
>> 
>> 
>> ls -l  provides the file size in terms of number of bytes used. Not sure
>> which incantation of ls s needed to get allocated blocks.
>
>ls -s gives the allocated blocks with a blocksize of 512. This can be 
>overridden by specifying a different size via the BLOCKSIZE environment 
>variable.
>
>ls -sk gives the number of allocated kilobytes, not blocks. This 
>overrides the environment variable BLOCKSIZE.
>
>
>> when you INIT, i believe that by default, it places some of the
>> structures in the middle of the disk.
>
>Thanks. That explains what I am seeing.
>
>> So the container file of say 1 gig would have some structure probably
>> written at the start and its middle, but nothing after. So the file
>> system would think the logical end of file is the highest byte written,
>> hence near the middle of the disk.
>
>A test with
>
>set -L rq3 rauser=100000
>
>$ INIT /INDEX=BEGINNING DUA3: DATA_3
>
>$ ls -s dua3.dsk
>1056 dua3.dsk
>$ ls -sk dua3.dsk
> 528 dua3.dsk
>
>$ INIT /INDEX=MIDDLE DUA3: DATA_3
>
>$ ls -s dua3.dsk
>51048 dua3.dsk
>$ ls -sk dua3.dsk
>25524 dua3.dsk
>
>$ INIT /INDEX= END DUA3: DATA_3
>
>$ ls -s dua3.dsk
>99992 dua3.dsk
>$ ls -sk dua3.dsk
>49996 dua3.dsk
>
>Not quite the full allocation, so:
>
>INIT /ERASE DUA3: DATA_3
>
>$ ls -s dua3.dsk
>100000 dua3.dsk
>$ ls -sk dua3.dsk
> 50000 dua3.dsk
>
>Oh, ls -skl also works:
>
>$ ls -skl dua3.dsk
> 50000 -rw-r--r--  1 simh  staff  51199488 Nov 24 16:54 dua3.dsk
>
>FWIW doing an INIT /ERASE on a 30GB disk took about 1 hour 10 minutes on 
>my 1.5 GHZ PowerBook. I might play with some FDL file placement to speed 
>things up here :-)

Faster might be to zap the file from the Mac's command line.

# dd if=/dev/zero of=/Users/PaulSture/dua3.dsk

(Or whatever the directory path of your dua3.dsk may be.)

Then, VMS INIT the disk.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"

In article <00A95082.8F0DA36A@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:
>In article <paul.nospam-BA3995.17084224112009@pbook.sture.ch>, Paul Sture <paul.nospam@sture.ch> writes:
>>In article <00832f91$0$1610$c3e8da3@news.astraweb.com>,
>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>
>>> Paul Sture wrote:
>>> 
>>> > Now you have me wondering if what I am seeing is a feature of the OS X 
>>> > file system.
>>> 
>>> 
>>> ls -l  provides the file size in terms of number of bytes used. Not sure
>>> which incantation of ls s needed to get allocated blocks.
>>
>>ls -s gives the allocated blocks with a blocksize of 512. This can be 
>>overridden by specifying a different size via the BLOCKSIZE environment 
>>variable.
>>
>>ls -sk gives the number of allocated kilobytes, not blocks. This 
>>overrides the environment variable BLOCKSIZE.
>>
>>
>>> when you INIT, i believe that by default, it places some of the
>>> structures in the middle of the disk.
>>
>>Thanks. That explains what I am seeing.
>>
>>> So the container file of say 1 gig would have some structure probably
>>> written at the start and its middle, but nothing after. So the file
>>> system would think the logical end of file is the highest byte written,
>>> hence near the middle of the disk.
>>
>>A test with
>>
>>set -L rq3 rauser=100000
>>
>>$ INIT /INDEX=BEGINNING DUA3: DATA_3
>>
>>$ ls -s dua3.dsk
>>1056 dua3.dsk
>>$ ls -sk dua3.dsk
>> 528 dua3.dsk
>>
>>$ INIT /INDEX=MIDDLE DUA3: DATA_3
>>
>>$ ls -s dua3.dsk
>>51048 dua3.dsk
>>$ ls -sk dua3.dsk
>>25524 dua3.dsk
>>
>>$ INIT /INDEX= END DUA3: DATA_3
>>
>>$ ls -s dua3.dsk
>>99992 dua3.dsk
>>$ ls -sk dua3.dsk
>>49996 dua3.dsk
>>
>>Not quite the full allocation, so:
>>
>>INIT /ERASE DUA3: DATA_3
>>
>>$ ls -s dua3.dsk
>>100000 dua3.dsk
>>$ ls -sk dua3.dsk
>> 50000 dua3.dsk
>>
>>Oh, ls -skl also works:
>>
>>$ ls -skl dua3.dsk
>> 50000 -rw-r--r--  1 simh  staff  51199488 Nov 24 16:54 dua3.dsk
>>
>>FWIW doing an INIT /ERASE on a 30GB disk took about 1 hour 10 minutes on 
>>my 1.5 GHZ PowerBook. I might play with some FDL file placement to speed 
>>things up here :-)
>
>Faster might be to zap the file from the Mac's command line.
>
># dd if=/dev/zero of=/Users/PaulSture/dua3.dsk

I forgot to mention to specify 'count' in the above.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"

In article <paul.nospam-F40C1F.14523623112009@pbook.sture.ch>,
 Paul Sture <paul.nospam@sture.ch> wrote:

> In article <7mvh5rF3gke5iU40@mid.individual.net>,
>  Bob Eager <rde42@spamcop.net> wrote:
>
> > Does INIT/ERASE write nonzero values to every block? Don't have the 
> > manual handy.
> 
> Yes it does. From V7.3 HELP INIT /ERASE
> 
> "If you specify the /ERASE qualifier, a DSE operation is performed
> on the volume. For disk devices, the ERASE volume attribute is
> set. In effect, each file on the volume is erased when it is
> deleted."
> 
> I note that on V8.3 there are also /ERASE=INIT and /ERASE=DELETE, which 
> allow you to specify the DSE operation and the volume attribute 
> respectively, /ERSASE=(INIT,DELETE) being the default.
> 

Someone kindly contacted me offline about this.

Unless you've specifically added the pattern overwrite service $erapat 
into your configuration, the DSE is a zero-overwrite of the whole disk.

(In VAX-VMS V7.3, see DOD_ERAPAT.MAR and DOD_ERAPAT_LNK.COM in 
SYS$EXAMPLES. I don't see it in SYS$EXAMPLES on Alpha V8.3. I'll mention 
that I've only ever come across one customer whose evaluation list had 
the ability to incorporate their own algorithm here, and it was 
government site.)

-- 
Paul Sture

Paul Sture wrote:

> FWIW doing an INIT /ERASE on a 30GB disk took about 1 hour 10 minutes on 
> my 1.5 GHZ PowerBook. I might play with some FDL file placement to speed 
> things up here :-)


is it really necesssary ?

If the underlying file system is smart enough to give you a brand
spanking "fresh off the press" block filled with steaming zeros topped
with whipped cream whenever you request a block that has not yet been
allocated, wouldn't the emulated VAX still see a 30 gig drive  where any
unwritten blocks are filled with 0s, no matter where they might be ?


OS-X brags about fragmentation not being an issue, and I have no idea
how it does this.  From a legacy point of view, it would seem that
allocating your 30 gig drive in one shot would make more sense from a
performance point of view since it is more chances oif it being
contiguous. Doing on-demand allocation may work, but can it still yield
efficiently organised contiguous allocations ?

In article <00881af7$0$17034$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
>OS-X brags about fragmentation not being an issue, and I have no idea
>how it does this.  From a legacy point of view, it would seem that
>allocating your 30 gig drive in one shot would make more sense from a
>performance point of view since it is more chances oif it being
>contiguous. Doing on-demand allocation may work, but can it still yield
>efficiently organised contiguous allocations ?

You will find a periodic dunp/restore will convince you otherwise.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"

In article <00881af7$0$17034$c3e8da3@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> Paul Sture wrote:
> 
> > FWIW doing an INIT /ERASE on a 30GB disk took about 1 hour 10 minutes on 
> > my 1.5 GHZ PowerBook. I might play with some FDL file placement to speed 
> > things up here :-)
> 
> 
> is it really necesssary ?
> 
> If the underlying file system is smart enough to give you a brand
> spanking "fresh off the press" block filled with steaming zeros topped
> with whipped cream whenever you request a block that has not yet been
> allocated, wouldn't the emulated VAX still see a 30 gig drive  where any
> unwritten blocks are filled with 0s, no matter where they might be ?
> 

What triggered my interest here was the possibility of running out of 
free space in VMS/SIMH when you _think_ you have plenty to go at.

I did try an INIT/INDEX=END on a disk which was too big for the 
available free space and it chucked me back to the sim> prompt. Typing a 
'c' at that point brought me back into VMS and issued an I/O error, but 
I didn't know what would happen until I tried it.

-- 
Paul Sture

In article <00A95083.8C600D12@SendSpamHere.ORG>,
 VAXman-  @SendSpamHere.ORG wrote:

> ># dd if=/dev/zero of=/Users/PaulSture/dua3.dsk
> 
> I forgot to mention to specify 'count' in the above.

Much faster thanks.

-- 
Paul Sture