SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Fri, 20 Nov 1998 05:43:50 PDT
From:	dallasii@kincyb.com
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: More2queue2stuff

I need to thank Steve Levine for helping me out on my multitasking experiment.

PS>
PS> Date: Thu, 19 Nov 1998 09:11:06 PDT
PS> Reply-To: scoug-programming@scoug.com
PS> From: Peter Skye
PS> To: scoug-programming@scoug.com
PS> Subject: SCOUG-Programming: More\1b[1;33m2queue\1b[1;33m2stuff\1b[0m
PS>
PS> dallasii@kincyb.com wrote:
PS> >
PS> > ... I just did a test and confirmed that QUEUED()
PS> > returns the # of lines in the queue, and not the # of characters.
PS> > This should eliminate any need to put the count back on the top
PS> > of the queue.
PS>
PS> Thanks. So you just need a code on each entry to keep track of which
PS> line you're currently at (so you know when you're back at the
PS> beginning).
PS>
PS> > Since the things are global not just to the program, but to the OS,
PS> > you should never have to EXPOSE the queue itself (and probably can't),
PS> > just a variable holding it's name.
PS>
PS> Yes.
PS>
PS> > This should also work if you're not index/counting the items,
PS> > but using a hash/association type structure for tracking the
PS> > members.

The term I should of remembered here is 'key'.
pure associative hashed vrs. ordinal number indexed/hashed.

PS>
PS> My specific application is for an HTML generator for a 200 MB database.
PS> I have to start at the first entry of the stem/queue and read the entire
PS> set of lines in sequence. The lines are either for an HTML page where I
PS> replace some proprietary tags with the appropriate text or HTML (for

Is it possible some of this stuff could be preprocessed before it even gets
read into ReXX space with SED, or even PERL running in it's default
stream editing mode (which is not much more than a super-SED)?
SED is another program I'm big on right now, just because of it's
high power * simplicity product.
One of the first things I did when I got Web access to a search engine
was to do a search on ReXX. I should of downloaded it, but
I came across a page where a guy was describing his integration
of a project using Rexx, where he used a lot of small bits of
C and PERL for the things they were good at, but glued it all
together with Rexx because of what it was good for - easy to read
and quick to learn the basics (in case it needs to be maintained
by non-specialists/non-uber-hackers)
The guys point was to challenge the predominant idea of "REXX vrs. PERL",
and instead show them in harmony.
I kick out SED as an idea because it's relatively easy to learn,
easy to install etc.
I'm suggesting preprocessing as much as possible because I really
don't know how fast these queues will perform, so maybe you want as
much work done before hand as possible, or how well they are supported
on NT (you mention below some of their systems use it - God help them,
in my opinion). You might want to run some simple tests or check
reference info
on any ReXX running on NT to see what the queue support there is.
Another idea might be to use REXX to write a bunch of custom
SED scripts and launch pipelines of these on background....
hey, this sounds like my experiment Steve L. pointed out the
obvious problem on! (just not running in a Korn Shell environment,
it should be a lot easier to get it to work!)
There's some more stuff I could blather on about this, let me know if
you want any more, this is enough for now.

PS> example, change "&partno;" to the actual part number of the item
PS> described on that page), or a parameter file which contains font
PS> defaults and stuff like that which are then used on the HTML pages
PS> (there aren't too many defaults, so right now I'm just starting at the
PS> beginning of the default list and reading it until I find the default I
PS> want). I'm generating about 50,000 HTML pages.
PS>
PS> The site was running off of a non-OS/2 database (Microsoft Access 97
PS> running on Windows NT) and was having problems:
PS>
PS> 1. The site wasn't flexible enough due to how the hosting service had
PS> set up its database services.
PS> 2. Also, there was a business decision to go to pre-generated HTML
PS> because the company uses an outside web hosting service for its site and
PS> doesn't like the idea of being locked into writing code for one specific
PS> database (you can't quickly switch to a different provider). HTML is
PS> universal.
PS> 3. Also, there were some concerns about the site being slower if the
PS> HTML pages had to be put together on the fly instead of just having the
PS> HTML pages sitting there ready to go. Not an issue if the host database
PS> isn't working hard, but when a lot of queries come in simultaneously
PS> your slice of time is spent accessing and assembling the page rather
PS> than just squirting it out onto the Internet. When the server slows
PS> down, straight HTML wins the race.
PS>
PS> This generation of a lot of HTML pages is a "brute force" method with
PS> both pros and cons, and the decision was to drop the database server
PS> method and use pre-generated HTML pages.
PS>
PS> I'm writing it in REXX because I don't want to support it when it's
PS> done, and the company that's getting it should be able to do so if it's
PS> in REXX (no specific compilers required). I considered using Java, but
PS> I'm really not up to speed on Java yet and this project is on a tight
PS> deadline ("they needed it yesterday"). The company uses both OS/2 and
PS> Windows NT and has no concerns at all about my using REXX. (I did, but
PS> that's a different story.)
PS>
PS> Dallas, I owe you a muffin. :)

I'd settle for a reference, however meager! :-)

PS>
PS> - Peter
PS>
PS>

Regards,
Dallas E. Legan II
(562) 862 - 4854 ext. '*'

L
E
G
A
N
@
A
C
M
.
O
R
G

=====================================================

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 [ 20 | November | 1998 ]

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.