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. <plug> 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. </plug> Thanks Mark Johnson ----- Original Message ----- From: "Ron Sharcott" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> 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 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: <u2-users@listserver.u2ug.org> > 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 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 - <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/
