SCOUG-Programming Mailing List Archives
Return to [ 19 |
November |
1998 ]
Content Type: text/plain
dallasii@kincyb.com wrote:
>
> ... I just did a test and confirmed that QUEUED()
> returns the # of lines in the queue, and not the # of characters.
> This should eliminate any need to put the count back on the top
> of the queue.
Thanks. So you just need a code on each entry to keep track of which
line you're currently at (so you know when you're back at the
beginning).
> Since the things are global not just to the program, but to the OS,
> you should never have to EXPOSE the queue itself (and probably can't),
> just a variable holding it's name.
Yes.
> This should also work if you're not index/counting the items,
> but using a hash/association type structure for tracking the
> members.
My specific application is for an HTML generator for a 200 MB database.
I have to start at the first entry of the stem/queue and read the entire
set of lines in sequence. The lines are either for an HTML page where I
replace some proprietary tags with the appropriate text or HTML (for
example, change "&partno;" to the actual part number of the item
described on that page), or a parameter file which contains font
defaults and stuff like that which are then used on the HTML pages
(there aren't too many defaults, so right now I'm just starting at the
beginning of the default list and reading it until I find the default I
want). I'm generating about 50,000 HTML pages.
The site was running off of a non-OS/2 database (Microsoft Access 97
running on Windows NT) and was having problems:
1. The site wasn't flexible enough due to how the hosting service had
set up its database services.
2. Also, there was a business decision to go to pre-generated HTML
because the company uses an outside web hosting service for its site and
doesn't like the idea of being locked into writing code for one specific
database (you can't quickly switch to a different provider). HTML is
universal.
3. Also, there were some concerns about the site being slower if the
HTML pages had to be put together on the fly instead of just having the
HTML pages sitting there ready to go. Not an issue if the host database
isn't working hard, but when a lot of queries come in simultaneously
your slice of time is spent accessing and assembling the page rather
than just squirting it out onto the Internet. When the server slows
down, straight HTML wins the race.
This generation of a lot of HTML pages is a "brute force" method with
both pros and cons, and the decision was to drop the database server
method and use pre-generated HTML pages.
I'm writing it in REXX because I don't want to support it when it's
done, and the company that's getting it should be able to do so if it's
in REXX (no specific compilers required). I considered using Java, but
I'm really not up to speed on Java yet and this project is on a tight
deadline ("they needed it yesterday"). The company uses both OS/2 and
Windows NT and has no concerns at all about my using REXX. (I did, but
that's a different story.)
Dallas, I owe you a muffin. :)
- Peter
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 19 |
November |
1998 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
|