RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Stevenson, Charles]

Just now reading u2 list from last couple weeks. 

> From: Ray Wurlod
> Sent: Monday, October 16, 2006 7:52 PM
> 
> ...dictionaries   you can move 
> I-descriptors to some other file, and reference them via "R" 
> (remote) types.  I can't find it documented, ...

I've also done that when I've needed the same calculation in multiple
dictionaries, but wanted to maintain it in one place.  Call it Code
Reuse.
You might need to be careful when recompiling dictionaries, though.
---
Benton doesn't like VOC R-items if the file referenced in line 2 is a
Q-pointer.  Needs to be an F-pointer.  Maybe that's corrected in a
version later than mine.
---
I remember as a kid, first encountering "(sic)" in a newspaper, where
the paper was quoting someone's poor grammar.  I thought it was an
editorial comment by the reporter saying he was disgusted by the poor
grammar, meaning "that's just sick!"
e.g. = exempli gratia (Latin), for the sake of example.
i.e. = id est (Latin), that is.
I often see people mistakenly use those two interchangeable. Mnemonic
device: think "Egzample".
The two periods are proper; i.e., do not write "eg." or "ie.".
I had never heard "backronym" before.  I like it.
And we all know the difference between acronyms and abbreviations, don't
we?
(All this from a guy who routinely posts spelling errors!)

cds
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[TPellitieri]

Jeff Schasny <[EMAIL PROTECTED]> wrote on Thu, 19 Oct 2006 10:32:55
-0600

> Much as I hate to make editorial comments on a very nice
> writeup, I'd hate for you to go on misusing [sic].

Thanks for the full reference, Jeff.  I would have said something if you
hadn't.

There are two other Latin abbreviations in common usage that are often
misused:

1) e.g. - exampli gratia - for example
2) i.e. - id est - that is

Too often, I see "i.e." when "e.g." is correct.  "i.e." is used to reword
or explain, while "e.g." gives a sample.  However, when the sample is the
only choice, "i.e." is correct.  The following statements illustrate this.

As most MV programmers know, it is important to choose an appropriate
modulo (i.e., a prime number) for file sizing, but using an excessively
large value on a dictionary (e.g., 10,007) is probably not a good idea.
Anyone from my home town (i.e., Tonawanda, NY) is welcome to contact me
directly.

(Had to keep this on topic, right? :->)

--Tom Pellitieri
  Toledo, Ohio
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Tony Gravagno]

Mark Johnson wrote:
> In 1978 ... I recall him reviewing a FOR...NEXT loop that had the FOR
part in one
> frame and the NEXT part in another and he was spending time trying to
> put compilable code (not comments) in front of the FOR section in the
> hope that the both the FOR and NEXT were in the same frame. This may
> have had the moniker "Frame Faulting". Mainframes called this a Core
> Dump.

I'm not sure how much the following applies to U2 environments anymore but
I'd be interested if someone compared the info below to how U2 works now
and in the past.

The term Frame Faulting refers to the process where the DBMS is scanning
for data and it encounters an end of frame before the end of the data it
needs.  So it looks at the frame forward link, performs a frame read,
attaches the resulting data to the buffer in memory, then it goes back to
scanning.  It's a time consuming process that is best avoided where
possible, and that's why we all fight so hard to keep data out of overflow.

Pursuant to this discussion, if you have a Mod 1 file and need to
constantly frame fault just looking for item IDs, you're putting an
unnecessary burden on the environment.  Doesn't the same thing happen when
the Mod is larger?  No and yes.  Data is physically read from disk in
chunks.  Over the years the frame size in MV environments has closely
followed the physical disk read size (an even disk sector in most cases),
which is why we've seen an evolution from 512 to 1024, 2048, etc.  Disk
drives (and utilization of memory cache and intelligent read-ahead
software) are always far ahead of MV, and in a single read they'll read an
entire track of several contiguous sectors (contiguous frames) so that the
next sequential frames (primary frame of the next group) has probably
already been read into memory by the time the database decides that it has
finished with one group and it needs the next one.  These days that
technology is so far ahead of MV that selective placement of data on disk
just isn't worth the time.  There is so much data in memory, and disk
drives allocate and reallocate data based on errors detected and many other
factors - we can't predict like we used to exactly where the heads are
going to find our data.

 
> Perhaps his age at the time (50?) indicated a respect for the
> incredibly precious resources that he was used to and the disciplines
> that he had to adhere to. In the last 28 years of my MV programming I
> have never recalled having to be so anal as to perform such a
> lower-level observation for such an unmeasurable improvement.

Just for reference, back in the 80's I also used to do that sort of thing
on R83, GA, Microdata, Ultimate, and maybe ADDS or other platforms.  But
when Pick started running on a host OS, all bets were off as some other
kernel or hardware disk controller was now in control of disk access.  The
requirement for doing this was less for performance and more because from
one release to the next, the DBMS environments would have problems frame
faulting for object code, procs, MD entries, etc..

Tony
TG@ removethisNebula-RnD.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

I had such an occurrence where someone was creating an additional data-level
file on an existing dict/data file set. So he typed:

CREATE-FILE DATA EXISTINGFILE NEWDATALEVEL 1,1 1,1

assuming that the 1,1 pertained to the dict and the 1,1 applied to the
new datalevel that they were creating. The 1,1 was ignored

While D3 and native systems reply with the base and mod frame numbers of the
new file, it wasn't read by the programmer. But when the new datalevel file
was put into production, the client called in a few weeks as it got
hammered. There was some egg on the face of that programmer, especially
reviewing the TCL-STACK file (big brother) for the typed command.

FYI
Mark Johnson
- Original Message -
From: <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 11:51 AM
Subject: RE: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM &
RM


> Mark
>
>  >Today's numbers are downright staggering in the MV world.
>
> A couple of weeks ago I had to repair a failed RedBack implementation.
>
> The garbage collection wasn't running, and so their state file had grown
to being a mere 15,000 times undersized.
>
> Strangely enough, this eventually led to corruption and decay. But it must
have been running a long while before it did.
>
> and, yes, I left the tuning manual and garbage collection instructions on
the guy's desk.
>
> 
>
> Brian
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M

[Mark Johnson]

You're welcome.

In another magazine that I write for, I've been labeled "The Resident
Curmudgeon". I guess my age shows up not believeing (or wanting to believe)
things that others may get excited about.

Oddly enough I have a brother who writes HTML in Wordpad and despite my
suggestions, he's become pretty profecient with it. I guess the same can be
said for Jurrasic Pick programmers like myself who have lived 100 years in
ED BP ABC with the L22 editor. I now use WED from Accuterm and many on this
forum use other modern tools for managing these text files we call programs.
Some even use vi as their preferred editor.

Using programming tools like SB, GED and the other hamburger helper 4GL's,
we are spared from the tedious nature of the generic MV EDitor. On the other
hand, many people are still supporting and enhancing systems that were
written 10-25 years ago and one could wonder how they could write such
sophisticated applications with *only* the L22 editor. The average age of my
client's systems is 18 years.


I am enjoying using Accuterm with its GUI editor for making VB-looking forms
on top of the standard MV database and haven't been this excited about an MV
product since the creation of the EXECUTE command. Add their Windows Editor
WED and all of the connectivity stuff and sell it for $995 for 50 licenses
and it's a no brainer. All of my clients (except for those still on
Microdata) will be installing Accuterm and I will deliver happiness with the
GUI programs.


Thanks
Mark Johnson
- Original Message -
From: "Ron Sharcott" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 12:48 PM
Subject: RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M


> I enjoyed reading that and wanted to say thank you.
>
> Rapid Application Development (RAD) does not have to be sloppy and quick.
If
> slowed down a touch it can start to include a touch of quality. Often RAD
is
> taken to mean "just get it done" when really it means "roll it out when it
> can do the job" and "use prebuilt tools to do the job".
>
> Applications that assist RAD can be bloating if used without a watchful
eye.
> Editing HTML in Word is a prime example of that. At the same rate writing
> 100 pages of HTML using nothing but Notepad is a waste of time.
>
> Its all about balance.
>
> Thank you again.
>
>
> Ron Sharcott (3635)
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson
> Sent: Thursday, October 19, 2006 7:50 AM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM
>
>
> In observing this thread the words 'page size' caught my eye.
>
> In 1978 I remember a much older programmer working with me at Microdata
> (sic) reading very closely the Basic compiler output generated with the
MAP
> option. Microdata's compiler didn't (doesn't) generate the necessary file
> helpful with debugging programs automatically so you had to specify with
the
> (M option to generate it. It produced the variable table and laid out the
> basic code lines as they were spread out over the object code record.
>
> I recall him reviewing a FOR...NEXT loop that had the FOR part in one
frame
> and the NEXT part in another and he was spending time trying to put
> compilable code (not comments) in front of the FOR section in the hope
that
> the both the FOR and NEXT were in the same frame. This may have had the
> moniker "Frame Faulting". Mainframes called this a Core Dump.
>
> So he would code and compile and review, code and compile and review until
> he felt it was right.
>
> Perhaps his age at the time (50?) indicated a respect for the incredibly
> precious resources that he was used to and the disciplines that he had to
> adhere to. In the last 28 years of my MV programming I have never recalled
> having to be so anal as to perform such a lower-level observation for such
> an unmeasurable improvement. I could never count the number of times I
typed
> the word "BASIC"
>
> I don't advocate sloppy programming or poor file design techniques. But
with
> today's incredibly fast, fast, fast, fast and large, large, large systems,
I
> believe there is also an unmeasurable element to over analyzing the
> tweaking.
>
> While it's easy to take an academic approach to the micro-managing of each
> CPU cycle and disc read, at some time it just really doesn't matter.
Granted
> if you create a file with a mod of 1 and try to cram 10 MB into it, the
> system will accomodate this gross error and reward you with a slower file.
>
> But if the file was created with a mod of 1001 (sic) and it shoul

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

I stand corrected. I've used (sic) for years and no-one has complained.
Perhaps they didn't know either.

I just don't want someone replying to a post because my editorial example
isn't technically correct, prime-wise. In this case, 3001 is prime but I
don't want to insure that all the other numbers are prime just for a
dissertation. It was for relative difference and an example only.

Thanks
Mark Johnson
- Original Message -
From: "Jeff Schasny" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, October 19, 2006 12:32 PM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> Much as I hate to make editorial comments on a very nice writeup, I'd
> hate for you to go on misusing [sic].
>
>  From the wikipedia (and correct as far as I have always known):
>
> /*Sic*/ is a Latin  word meaning "thus", "so", or
> "just as that". In writing, it is italicized and placed within square
> brackets   [/sic/]  to indicate that an incorrect or
> unusual spelling, phrase, or other preceding quoted material is a
> verbatim <http://en.wiktionary.org/wiki/verbatim> reproduction of the
> quoted original and is not a transcription error.
>
> This may be used either to show that an uncommon or archaic usage is
> reported faithfully (for instance, quoting the U.S. Constitution
> , "The House of Representatives
>  shall chuse [/sic/] their Speaker...")
> or to highlight an error, often for the purpose of ridicule or irony
> (for instance, "Dan Quayle  famously changed a
> student's spelling to 'potatoe ' [/sic/]"), or otherwise,
> to quote accurately whilst maintaining the reputation of the person or
> organisation quoting its source.
>
> In folk etymology , "sic" is sometimes erroneously
> thought to be an abbreviation of "spelling is correct", "same in copy
> ", "spelled incorrectly", "spelling
> incompetent", "said in context", "stupid in context", "stand incorrect",
> or "spelling intentionally changed", to cite but a few backronyms
> .
>
>
>
> Mark Johnson wrote:
> > But if the file was created with a mod of 1001 (sic) and it should have
been
> > 1401 (sic), how measurably different is the delay with the 40%
undersized
> > file of 1001? (PS for those who don't know, (sic) means example. Don't
reply
> > with lessons on prime numbers. It's just an example).
> >
> [large amounts of stuff trimmed]
>
> --
> ==
>  Jeff Schasny
>  jschasnyATricochetDOTcom
> ==
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] VOCLIB and keeping VOC entries Short and Small, IM & R M

[Ron Sharcott]

I enjoyed reading that and wanted to say thank you. 

Rapid Application Development (RAD) does not have to be sloppy and quick. If
slowed down a touch it can start to include a touch of quality. Often RAD is
taken to mean "just get it done" when really it means "roll it out when it
can do the job" and "use prebuilt tools to do the job".

Applications that assist RAD can be bloating if used without a watchful eye.
Editing HTML in Word is a prime example of that. At the same rate writing
100 pages of HTML using nothing but Notepad is a waste of time.

Its all about balance.

Thank you again.


Ron Sharcott (3635)


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson
Sent: Thursday, October 19, 2006 7:50 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


In observing this thread the words 'page size' caught my eye.

In 1978 I remember a much older programmer working with me at Microdata
(sic) reading very closely the Basic compiler output generated with the MAP
option. Microdata's compiler didn't (doesn't) generate the necessary file
helpful with debugging programs automatically so you had to specify with the
(M option to generate it. It produced the variable table and laid out the
basic code lines as they were spread out over the object code record.

I recall him reviewing a FOR...NEXT loop that had the FOR part in one frame
and the NEXT part in another and he was spending time trying to put
compilable code (not comments) in front of the FOR section in the hope that
the both the FOR and NEXT were in the same frame. This may have had the
moniker "Frame Faulting". Mainframes called this a Core Dump.

So he would code and compile and review, code and compile and review until
he felt it was right.

Perhaps his age at the time (50?) indicated a respect for the incredibly
precious resources that he was used to and the disciplines that he had to
adhere to. In the last 28 years of my MV programming I have never recalled
having to be so anal as to perform such a lower-level observation for such
an unmeasurable improvement. I could never count the number of times I typed
the word "BASIC"

I don't advocate sloppy programming or poor file design techniques. But with
today's incredibly fast, fast, fast, fast and large, large, large systems, I
believe there is also an unmeasurable element to over analyzing the
tweaking.

While it's easy to take an academic approach to the micro-managing of each
CPU cycle and disc read, at some time it just really doesn't matter. Granted
if you create a file with a mod of 1 and try to cram 10 MB into it, the
system will accomodate this gross error and reward you with a slower file.

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).

I tried this years ago on a single user system (multiple user systems are
much harder to truly measure with the other user's affect). IIRC I had a
file that needed a 3001 (sic) modulo and I loaded it from tape into
different file sizes ranging from 11, 101, the calculated 3001 and even
15001. I performed some crude timing tests, ie sorting, read/re-write etc
and came away with the impression that it really doesn't matter unless it's
tremendously undersized. The 11 size file was the poorest but the 101, 501
and 15001 were suprisingly close to the 'preferred' 3001. IIRC even having
some non-prime modulos near 3001 and it didn't matter either.

I haven't tried this test recently but I can imagine that the results would
be quicker but the shot-group would be the same if not tighter. I don't know
about U2 systems, but D3 systems have long dropped the separation value in
creating files with the assumption of '1'. That closes that chapter on file
calculations.

I can't imagine justifying the process to analyze and re-analyze this today.
Perhaps I'm wrong and someone managing a 10,000 user system will babble
about every precious CPU. But for the rest of us it is an entertaining
distraction that would be hard to cost-justify. We don't have a 10 MB hard
drive system supporting 16 users with 32K of core memory anymore. Today's
numbers are downright staggering in the MV world.

My 101,1 cents
Mark Johnson

- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 18, 2006 5:06 AM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> In message 
> <[EMAIL PROTECTED]>, Adrian 
> Merrall <[EMAIL PROTECTED]> writes
> >> And on, and on, 

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Jeff Schasny]

Much as I hate to make editorial comments on a very nice writeup, I'd 
hate for you to go on misusing [sic].


From the wikipedia (and correct as far as I have always known):

/*Sic*/ is a Latin  word meaning "thus", "so", or 
"just as that". In writing, it is italicized and placed within square 
brackets   [/sic/]  to indicate that an incorrect or 
unusual spelling, phrase, or other preceding quoted material is a 
verbatim  reproduction of the 
quoted original and is not a transcription error.


This may be used either to show that an uncommon or archaic usage is 
reported faithfully (for instance, quoting the U.S. Constitution 
, "The House of Representatives 
 shall chuse [/sic/] their Speaker...") 
or to highlight an error, often for the purpose of ridicule or irony 
(for instance, "Dan Quayle  famously changed a 
student's spelling to 'potatoe ' [/sic/]"), or otherwise, 
to quote accurately whilst maintaining the reputation of the person or 
organisation quoting its source.


In folk etymology , "sic" is sometimes erroneously 
thought to be an abbreviation of "spelling is correct", "same in copy 
", "spelled incorrectly", "spelling 
incompetent", "said in context", "stupid in context", "stand incorrect", 
or "spelling intentionally changed", to cite but a few backronyms 
.




Mark Johnson wrote:

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).
  

[large amounts of stuff trimmed]

--
==
Jeff Schasny
jschasnyATricochetDOTcom
==
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[brian]

Mark

 >Today's numbers are downright staggering in the MV world. 

A couple of weeks ago I had to repair a failed RedBack implementation.

The garbage collection wasn't running, and so their state file had grown to 
being a mere 15,000 times undersized.

Strangely enough, this eventually led to corruption and decay. But it must have 
been running a long while before it did.

and, yes, I left the tuning manual and garbage collection instructions on the 
guy's desk.



Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Mark Johnson]

In observing this thread the words 'page size' caught my eye.

In 1978 I remember a much older programmer working with me at Microdata
(sic) reading very closely the Basic compiler output generated with the MAP
option. Microdata's compiler didn't (doesn't) generate the necessary file
helpful with debugging programs automatically so you had to specify with the
(M option to generate it. It produced the variable table and laid out the
basic code lines as they were spread out over the object code record.

I recall him reviewing a FOR...NEXT loop that had the FOR part in one frame
and the NEXT part in another and he was spending time trying to put
compilable code (not comments) in front of the FOR section in the hope that
the both the FOR and NEXT were in the same frame. This may have had the
moniker "Frame Faulting". Mainframes called this a Core Dump.

So he would code and compile and review, code and compile and review until
he felt it was right.

Perhaps his age at the time (50?) indicated a respect for the incredibly
precious resources that he was used to and the disciplines that he had to
adhere to. In the last 28 years of my MV programming I have never recalled
having to be so anal as to perform such a lower-level observation for such
an unmeasurable improvement. I could never count the number of times I typed
the word "BASIC"

I don't advocate sloppy programming or poor file design techniques. But with
today's incredibly fast, fast, fast, fast and large, large, large systems, I
believe there is also an unmeasurable element to over analyzing the
tweaking.

While it's easy to take an academic approach to the micro-managing of each
CPU cycle and disc read, at some time it just really doesn't matter. Granted
if you create a file with a mod of 1 and try to cram 10 MB into it, the
system will accomodate this gross error and reward you with a slower file.

But if the file was created with a mod of 1001 (sic) and it should have been
1401 (sic), how measurably different is the delay with the 40% undersized
file of 1001? (PS for those who don't know, (sic) means example. Don't reply
with lessons on prime numbers. It's just an example).

I tried this years ago on a single user system (multiple user systems are
much harder to truly measure with the other user's affect). IIRC I had a
file that needed a 3001 (sic) modulo and I loaded it from tape into
different file sizes ranging from 11, 101, the calculated 3001 and even
15001. I performed some crude timing tests, ie sorting, read/re-write etc
and came away with the impression that it really doesn't matter unless it's
tremendously undersized. The 11 size file was the poorest but the 101, 501
and 15001 were suprisingly close to the 'preferred' 3001. IIRC even having
some non-prime modulos near 3001 and it didn't matter either.

I haven't tried this test recently but I can imagine that the results would
be quicker but the shot-group would be the same if not tighter. I don't know
about U2 systems, but D3 systems have long dropped the separation value in
creating files with the assumption of '1'. That closes that chapter on file
calculations.

I can't imagine justifying the process to analyze and re-analyze this today.
Perhaps I'm wrong and someone managing a 10,000 user system will babble
about every precious CPU. But for the rest of us it is an entertaining
distraction that would be hard to cost-justify. We don't have a 10 MB hard
drive system supporting 16 users with 32K of core memory anymore. Today's
numbers are downright staggering in the MV world.

My 101,1 cents
Mark Johnson

----- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, October 18, 2006 5:06 AM
Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM


> In message
> <[EMAIL PROTECTED]>, Adrian
> Merrall <[EMAIL PROTECTED]> writes
> >> And on, and on, until the particular bit of data is found.
> >> So... (this being one of the overwhelmingly elegant things about the
> >> Pickuverse) this means that in a properly sized hashed file NO MATTER
> >> HOW BIG it only takes one disk read to get to any record given a known
> >> key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can
do
> >> that. Stand back though, they tend to sputter alot.
> >
> >But won't this only work if your data fits into the modulo that
> >matches your page size?  If your data is lumpy and doesn't nicely fit
> >into the page size/file modulo selected you get level 1overflow and
> >more disk IO.
> >
> The stats I've come across (yes, they're old, they came from Prime) say
> that PROVIDED Adrian's "properly sized" caveat is followed, even when

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Anthony W. Youngman]

In message 
<[EMAIL PROTECTED]>, Adrian 
Merrall <[EMAIL PROTECTED]> writes

And on, and on, until the particular bit of data is found.
So... (this being one of the overwhelmingly elegant things about the
Pickuverse) this means that in a properly sized hashed file NO MATTER
HOW BIG it only takes one disk read to get to any record given a known
key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can do
that. Stand back though, they tend to sputter alot.


But won't this only work if your data fits into the modulo that
matches your page size?  If your data is lumpy and doesn't nicely fit
into the page size/file modulo selected you get level 1overflow and
more disk IO.

The stats I've come across (yes, they're old, they came from Prime) say 
that PROVIDED Adrian's "properly sized" caveat is followed, even when 
you have level 1 overflow and lumpy data, your 1 merely increases to an 
average of 1.05. In other words, 19 out of 20 attempts still hit first 
time...


Cheers,
Wol
--
Anthony W. Youngman <[EMAIL PROTECTED]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Dan Fitzgerald]

Yes, and this is where the art and work of dba comes in, as well as why one 
of the biggest (imho) vulnerabilities of the mv market has been the lack of 
conscious architecting, at least in legacy systems. Lumpy files are very 
often the result of a programmer creating a record that can potentially be 
needlessly large; think of a transaction batch file with the transaction ids 
multivalued in a single attribute; now imagine 100,000 keys in that field.


So, if you can redesign the file so that this kind of thing doesn't happen, 
great. If not, you'll probably want to get an idea of what's actually going 
on with file IO. If you turn FILE.USAGE on for a period of maybe 24 hours of 
typical usage(remember to turn it off again when you're done), and see what 
percentage of the IO is oversized buffer reads. If you're hammering the 
large items, it makes sense to go with a larger sep (Mark Baldridges recent 
excellent articles on this are a good resource for describing why you want 
to wince when you set sep to 16, and why there's a big hit when you go to 
32), and take the hit on making multiple physical disk reads on the more 
rarely accessed smaller items. But if you don't access those oversized items 
so much, you may want to tune for the rest of the file. Definitely a 
judgement call, and  Steve O'Neill will be happy to take your call if 
you need help with this .





But won't this only work if your data fits into the modulo that
matches your page size?  If your data is lumpy and doesn't nicely fit
into the page size/file modulo selected you get level 1overflow and
more disk IO.


_
Try Search Survival Kits: Fix up your home and better handle your cash with 
Live Search! 
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmtagline

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Timothy Snyder]

Adrian Merrall wrote on 10/17/2006 06:44:40 PM:

> But won't this only work if your data fits into the modulo that
> matches your page size?  If your data is lumpy and doesn't nicely fit
> into the page size/file modulo selected you get level 1overflow and
> more disk IO.

Good point.  And in case anybody is still thinking of setting up files 
with modulo 1 to improve performance, remember that UniVerse will 
associate all records in that file with a single lock semaphore, creating 
a potential bottleneck on the lock table.

Tim Snyder
Consulting I/T Specialist
U2 Consulting
North American Lab Services
IBM Software Group
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Adrian Merrall]

And on, and on, until the particular bit of data is found.
So... (this being one of the overwhelmingly elegant things about the
Pickuverse) this means that in a properly sized hashed file NO MATTER
HOW BIG it only takes one disk read to get to any record given a known
key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can do
that. Stand back though, they tend to sputter alot.


But won't this only work if your data fits into the modulo that
matches your page size?  If your data is lumpy and doesn't nicely fit
into the page size/file modulo selected you get level 1overflow and
more disk IO.

Looking forward, when USB sticks get big enough you can put all your
data on one.  No more disk reads and ultimate portability 8-)

Adrian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Adrian Merrall]

This is generally why your group size and OS
page size should be the same (yes, I know...unless you have some kind of
giant records, or dynamic files, or any of the other "YaBut's").



> So...this school of thought says that modulo 1 is a good thing, and
> that it forces files into memory.  The question is -- is the school of
> thought speculation, or is it true?


Whether to size files to OS page sizes or size the file to whatever
guide says is one of those subjects that we should invest some solid
benchmarking in as comments for and against seem to come up from time
to time.  I have a vague recollection Stephen O'Neill at IBM has
posted on this but I'll need more coffee to say for sure.

My limited understanding is...

If the file group is bigger than the page size then the OS will need
multiple reads to read it.  However, Linux (and I presume any modern
OS release) do predictive read-ahead and if you have a SAN, it should
also be doing the same thing.  Factor in the buffering also going on
in the OS and SAN and the answer is less clear.  While multiple read
requests may go out for the file group, if it is in an OS or SAN
buffer it will be coming back fast.  So on a properly spec'ed machine,
sizing the files according to guide and leaving the OS to do its job
is the best course of action?

Correction or comments welcome.

Regards,

Adrian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Jeff Schasny]

Blocksize/pagesize defines how much one disk read will bring in to 
memory at an OS level. The application calling for the disk read 
(Universe in this case) will then look for the data its searching for in 
memory and if it does not find it will request another disk read from 
the OS. And on, and on, until the particular bit of data is found.
So... (this being one of the overwhelmingly elegant things about the 
Pickuverse) this means that in a properly sized hashed file NO MATTER 
HOW BIG it only takes one disk read to get to any record given a known 
key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can do 
that. Stand back though, they tend to sputter alot.



[EMAIL PROTECTED] wrote:

[Large Snip]

So, in a nutshell, if your separation matches the blocksize, then one
group will be read at a time. How much of a file is read into memory at
once, then, depends on tunables, I think. (Help, someone correct me
now...)

Karl

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[karlp]

> So...this school of thought says that modulo 1 is a good thing, and
> that it forces files into memory.  The question is -- is the school of
> thought speculation, or is it true?

Briefly? The school was closed for lack of funding... It may have been a
private school.

Since uniVerse runs as a 'shell' over the OS, the disk reads, writes, and
caching are all done by the OS, therefore, the modulo and separation of
files should be matched to the segment size (blocksize) the OS is using.
On HP, the blocksize is(was) 2048K, or a separation of 4. There was a time
when matching that meant better data integrity because there were a lot of
things that caused files to become corrupt if the separation was a part of
the blocksize the OS used. File corruption has largely been made a thing
of the past, like polio and smallpox, because some bright programmers got
busy and solved some of the problems in the playground that kept U2 from
playing nicely with Mr. OS.

So, in a nutshell, if your separation matches the blocksize, then one
group will be read at a time. How much of a file is read into memory at
once, then, depends on tunables, I think. (Help, someone correct me
now...)

Karl

>
> On 10/16/06, Ray Wurlod <[EMAIL PROTECTED]> wrote:
>> Interestingly, at least in some flavors, you can do something similar
>> with file dictionaries.  In IDEAL flavor you can move I-descriptors to
>> some other file, and reference them via "R" (remote) types.  I can't
>> find it documented, but it did work when I tried it. I-descriptors are
>> 20+ fields long (maybe many more) and can be quite large, especially if
>> the expression is large.  The same considerations apply when searching
>> for a dictionary item from a query as for a VOC item.  How many of you
>> bother to tune your file dictionaries?  (There is another school of
>> thought that says leaving them with modulo 1 forces the entire
>> dictionary to be read into memory, leading to more efficient location of
>> subsequent items.  But if that were really the case, don't you think the
>> default size of the VOC file would be modulo 1 also?)
>> ---
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
>


-- 
karl

 _/  _/  _/  _/_/_/      __o
_/ _/   _/  _/_/   _-\<._
   _/_/_/  _/_/_/ (_)/ (_)
  _/ _/   _/  _/   ..
 _/   _/ arl _/_/_/  _/ earson[EMAIL PROTECTED]

--
IT Director, ATS Industrial Supply, Inc.
http://www.atsindustrial.com
Toll-free: 800-789-9300 x29
Direct2Desk: 801-978-4429
Facsimile: 801-972-3888
--
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Jeff Schasny]

The OS page size is what determines how much is read into memory on each 
disk read. So if your page size is 2k (not unusual) then only the first 
2k of your dictionary is going to be read in the first disk read 
regardless of your modulo. This is generally why your group size and OS 
page size should be the same (yes, I know...unless you have some kind of 
giant records, or dynamic files, or any of the other "YaBut's").


jjuser ud2 wrote:

So...this school of thought says that modulo 1 is a good thing, and
that it forces files into memory.  The question is -- is the school of
thought speculation, or is it true?

On 10/16/06, Ray Wurlod <[EMAIL PROTECTED]> wrote:
Interestingly, at least in some flavors, you can do something similar 
with file dictionaries.  In IDEAL flavor you can move I-descriptors 
to some other file, and reference them via "R" (remote) types.  I 
can't find it documented, but it did work when I tried it. 
I-descriptors are 20+ fields long (maybe many more) and can be quite 
large, especially if the expression is large.  The same 
considerations apply when searching for a dictionary item from a 
query as for a VOC item.  How many of you bother to tune your file 
dictionaries?  (There is another school of thought that says leaving 
them with modulo 1 forces the entire dictionary to be read into 
memory, leading to more efficient location of subsequent items.  But 
if that were really the case, don't you think the default size of the 
VOC file would be modulo 1 also?)

---

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/




--
==
Jeff Schasny
jschasnyATricochetDOTcom
==
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[jjuser ud2]

So...this school of thought says that modulo 1 is a good thing, and
that it forces files into memory.  The question is -- is the school of
thought speculation, or is it true?

On 10/16/06, Ray Wurlod <[EMAIL PROTECTED]> wrote:

Interestingly, at least in some flavors, you can do something similar with file 
dictionaries.  In IDEAL flavor you can move I-descriptors to some other file, and 
reference them via "R" (remote) types.  I can't find it documented, but it did 
work when I tried it. I-descriptors are 20+ fields long (maybe many more) and can be 
quite large, especially if the expression is large.  The same considerations apply when 
searching for a dictionary item from a query as for a VOC item.  How many of you bother 
to tune your file dictionaries?  (There is another school of thought that says leaving 
them with modulo 1 forces the entire dictionary to be read into memory, leading to more 
efficient location of subsequent items.  But if that were really the case, don't you 
think the default size of the VOC file would be modulo 1 also?)
---

---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Adrian Merrall]

How many of you bother to tune your file dictionaries?  (There is

another school of thought >that says leaving them with modulo 1 forces
the entire dictionary to be read into memory, >leading to more
efficient location of subsequent items.  But if that were really the
case, don't >you think the default size of the VOC file would be
modulo 1 also?)

If the DICT was big and the memory was limited it could be swap time
and that would completely trash the performance although for this to
happen on a DICT file the machine would pretty much be on its knees
anyway.

My assumption would be to size things properly and leave this kind of
low level tuning up to the kernel (and SAN if applicable) to handle
read-ahead and io buffering as it seems to do so well.

Adrian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Ray Wurlod]

Interestingly, at least in some flavors, you can do something similar with file 
dictionaries.  In IDEAL flavor you can move I-descriptors to some other file, 
and reference them via "R" (remote) types.  I can't find it documented, but it 
did work when I tried it. I-descriptors are 20+ fields long (maybe many more) 
and can be quite large, especially if the expression is large.  The same 
considerations apply when searching for a dictionary item from a query as for a 
VOC item.  How many of you bother to tune your file dictionaries?  (There is 
another school of thought that says leaving them with modulo 1 forces the 
entire dictionary to be read into memory, leading to more efficient location of 
subsequent items.  But if that were really the case, don't you think the 
default size of the VOC file would be modulo 1 also?)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM

[Stephen O'Neal]

Continuing with Mark's Comment, which is very important...

When the SELECT portion of the run engine is figuring out what to do, it 
looks:
1) First in the DICTionary of the file and then
2) In the VOC 

So, if what you need is at the end of a VOC disk record, or in overflow 
due to the lumpy VOC record, stuff slows down.

Cataloging programs increases the number of VOC entries greatly.  So, 
efficient use of the VOC can be very important.

PHrases are an example of this.  Since I hate to type (and I'm efficient) 
my favorites are:

ED VOC IM
1) PH
2) WITH @ID MATCHING

Which works like:
LIST VOC IM {string}...

Parses to:
LIST VOC WITH @ID MATCHING {string}...

and

ED VOC RM
1) PH
2) WITH @RECORD MATCHING

Which works like:
LIST VOC RM ...{string}...

Parses to:
LIST VOC WITH @RECORD MATCHING ...{string}...

Adding another penny...




"Mark Johnson" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
10/15/2006 04:02 PM
Please respond to
u2-users@listserver.u2ug.org


To

cc

Subject
Re: [U2] VOCLIB and keeping VOC entries Short and Small






Steve's suggestions are right on the money and have been for the past 30
years.

Virtually every one of my client's system, regardless of flavor, has had
this form of clutter. Oftentimes it's just as simple as copying the VOC 
item
to the VOCLIB (MD to PROCLIB etc) and changing the VOC item to reference 
the
VOCLIB item.

The VOC (MD) is rarely SELECTED but since all new items added to the VOC 
are
appended to the group, the 'lumpy' effect may make certain items appear
'slower'.

My 1 cent.
- Original Message -
From: "Stephen O'Neal" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, October 15, 2006 5:30 PM
Subject: [U2] VOCLIB and keeping VOC entries Short and Small


> The intent of VOCLIB is to reduce the VOC size.  One idea for speed is 
to
> keep your VOC very small.  This way the search for all items is faster.
>
> For some VOC items, like 'PA'ragrpahs and 'PR'ocs can be sizable (like
> 1,000's of characters).  This causes "Lumpy" records.  (To be shocked,
> sometime LIST VOC SIZE.)
>
> So, the intent was for people to make 'R'emote pointers and to put the
> larger sized items in the VOCLIB.
>
> Yes, if you do this, your system will run faster.
>
> Example:
>
> ED VOC LARGE.PARAGRAPH
> 1) R
> 2) VOCLIB
> 3) LARGE.PARAGRAPH
>
> ED VOCLIB LARGE.PARAGRAPH
> 1) PA Some really large description of the paragraph
> 2) SELECT
> 3) LIST...
>
> While you are at it, you should check your VOC for overflow, which will
> also slow down your system.
>
> For your education,
>Steve
>
>Stephen M. O'Neal
>Lab Services Sales for U2
>IBM SWG Information Management Lab Services
>
>
>
>
> "Anthony W. Youngman" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 10/15/2006 01:17 PM
> Please respond to
> u2-users@listserver.u2ug.org
>
>
> To
> u2-users@listserver.u2ug.org
> cc
>
> Subject
> Re: [U2][UV] UO.NET Help
>
>
>
>
>
>
> In message
> <[EMAIL PROTECTED]>, Nick
> Cipollina <[EMAIL PROTECTED]> writes
> >Paul,
> >
> >Thank you very much.  Turns out we were missing the VOCLIB file.  This
> >is a very useful piece of information.  Is this documented anywhere?
> >
> >Thanks,
> >
> >Nick Cipollina
> >
> I've got a feeling VOCLIB isn't created automatically. It's a Pr1me-ism,
> and doesn't contain anything by default, I don't think, so it's odd that
> it's required.
>
> That said, I've never seen an INFORMATION account without it, and I
> think the ODBC stuff originally came from Prime, so it's probably a
> historic hangover.
>
> Cheers,
> Wol
> --
> Anthony W. Youngman <[EMAIL PROTECTED]>
> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
> thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The
> man
> lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
> Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source
> Pick
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] VOCLIB and keeping VOC entries Short and Small

[Mark Johnson]

Steve's suggestions are right on the money and have been for the past 30
years.

Virtually every one of my client's system, regardless of flavor, has had
this form of clutter. Oftentimes it's just as simple as copying the VOC item
to the VOCLIB (MD to PROCLIB etc) and changing the VOC item to reference the
VOCLIB item.

The VOC (MD) is rarely SELECTED but since all new items added to the VOC are
appended to the group, the 'lumpy' effect may make certain items appear
'slower'.

My 1 cent.
- Original Message -
From: "Stephen O'Neal" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, October 15, 2006 5:30 PM
Subject: [U2] VOCLIB and keeping VOC entries Short and Small


> The intent of VOCLIB is to reduce the VOC size.  One idea for speed is to
> keep your VOC very small.  This way the search for all items is faster.
>
> For some VOC items, like 'PA'ragrpahs and 'PR'ocs can be sizable (like
> 1,000's of characters).  This causes "Lumpy" records.  (To be shocked,
> sometime LIST VOC SIZE.)
>
> So, the intent was for people to make 'R'emote pointers and to put the
> larger sized items in the VOCLIB.
>
> Yes, if you do this, your system will run faster.
>
> Example:
>
> ED VOC LARGE.PARAGRAPH
> 1) R
> 2) VOCLIB
> 3) LARGE.PARAGRAPH
>
> ED VOCLIB LARGE.PARAGRAPH
> 1) PA Some really large description of the paragraph
> 2) SELECT
> 3) LIST...
>
> While you are at it, you should check your VOC for overflow, which will
> also slow down your system.
>
> For your education,
>Steve
>
>Stephen M. O'Neal
>Lab Services Sales for U2
>IBM SWG Information Management Lab Services
>
>
>
>
> "Anthony W. Youngman" <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 10/15/2006 01:17 PM
> Please respond to
> u2-users@listserver.u2ug.org
>
>
> To
> u2-users@listserver.u2ug.org
> cc
>
> Subject
> Re: [U2][UV] UO.NET Help
>
>
>
>
>
>
> In message
> <[EMAIL PROTECTED]>, Nick
> Cipollina <[EMAIL PROTECTED]> writes
> >Paul,
> >
> >Thank you very much.  Turns out we were missing the VOCLIB file.  This
> >is a very useful piece of information.  Is this documented anywhere?
> >
> >Thanks,
> >
> >Nick Cipollina
> >
> I've got a feeling VOCLIB isn't created automatically. It's a Pr1me-ism,
> and doesn't contain anything by default, I don't think, so it's odd that
> it's required.
>
> That said, I've never seen an INFORMATION account without it, and I
> think the ODBC stuff originally came from Prime, so it's probably a
> historic hangover.
>
> Cheers,
> Wol
> --
> Anthony W. Youngman <[EMAIL PROTECTED]>
> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
> thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The
> man
> lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
> Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source
> Pick
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] VOCLIB and keeping VOC entries Short and Small

[Stephen O'Neal]

The intent of VOCLIB is to reduce the VOC size.  One idea for speed is to 
keep your VOC very small.  This way the search for all items is faster.

For some VOC items, like 'PA'ragrpahs and 'PR'ocs can be sizable (like 
1,000's of characters).  This causes "Lumpy" records.  (To be shocked, 
sometime LIST VOC SIZE.)

So, the intent was for people to make 'R'emote pointers and to put the 
larger sized items in the VOCLIB.

Yes, if you do this, your system will run faster.

Example:

ED VOC LARGE.PARAGRAPH
1) R
2) VOCLIB
3) LARGE.PARAGRAPH

ED VOCLIB LARGE.PARAGRAPH
1) PA Some really large description of the paragraph
2) SELECT
3) LIST...

While you are at it, you should check your VOC for overflow, which will 
also slow down your system.

For your education,
   Steve

   Stephen M. O'Neal
   Lab Services Sales for U2
   IBM SWG Information Management Lab Services




"Anthony W. Youngman" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
10/15/2006 01:17 PM
Please respond to
u2-users@listserver.u2ug.org


To
u2-users@listserver.u2ug.org
cc

Subject
Re: [U2][UV] UO.NET Help






In message 
<[EMAIL PROTECTED]>, Nick 
Cipollina <[EMAIL PROTECTED]> writes
>Paul,
>
>Thank you very much.  Turns out we were missing the VOCLIB file.  This
>is a very useful piece of information.  Is this documented anywhere?
>
>Thanks,
>
>Nick Cipollina
>
I've got a feeling VOCLIB isn't created automatically. It's a Pr1me-ism, 
and doesn't contain anything by default, I don't think, so it's odd that 
it's required.

That said, I've never seen an INFORMATION account without it, and I 
think the ODBC stuff originally came from Prime, so it's probably a 
historic hangover.

Cheers,
Wol
-- 
Anthony W. Youngman <[EMAIL PROTECTED]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The 
man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source 
Pick
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/