d3 printing a specific page only / max pages

d3 printing a specific page only / max pages

Post by ashel.. » Wed, 30 Apr 2003 02:38:19



Hello,

I would like to some how quickly print a specific page of a hold file
(hopefully to an item in a file) as well as quickly determine the max
pages in a hold file.  Are there any commands that can do this?

The application:

I'm creating a web based interface for showing html / pdf versions of
hold files on the system.  I would quickly like to display specific
pages without having to copy all the information in the entire hold
file at once.  

I know that I can do this by using an SP-EDIT hf# into a "session"
file and have each page accessible via page0001, page0002, page0003
etc.  But I'd much rather use the peqs file as the backend database.
(It'll save me some logic in the front end, cleaning up after users,
keeping track of things and stuff).

-Adam

 
 
 

d3 printing a specific page only / max pages

Post by Robert Herbi » Wed, 30 Apr 2003 03:37:11


I don't know of any TCL commands to do this, but what you want to do is
quite easy using Basic.

To determine the number of pages in a hold file:

EQU FF TO CHAR(12) ; * FORM FEED
OPEN 'PEQS' TO PEQS.FV ELSE STOP 201,'PEQS'
READ REC FROM PEQS.FV,HOLD.ENTRY THEN
  NBR.PGS = DCOUNT(REC,CHAR(12))
END ELSE
  NBR.PGS = 0
END

To print a specific page in a hold file, I would do as follows:

* ASSUMPTION, WE WANT TO PRINT PAGE N
DIM REC.DIM(NBR.PGS) ; * ALREADY DETERMINED NBR.PGS AS ABOVE
MATPARSE REC.DIM FROM REC USING FF
PRINT REC.DIM(N) ; * YOU SAID 'DISPLAY', BUT YOU GET THE IDEA

This requires the "on the fly" dimensioning of arrays.  I know this works
with D3, not sure about other pick variants.

I have found that using the CHAR(12) as the delimiter comes in handy for
retroactively numbering pages (pg 1 of 10, that sort of thing).

Robert Herbin


Quote:> Hello,

> I would like to some how quickly print a specific page of a hold file
> (hopefully to an item in a file) as well as quickly determine the max
> pages in a hold file.  Are there any commands that can do this?

> The application:

> I'm creating a web based interface for showing html / pdf versions of
> hold files on the system.  I would quickly like to display specific
> pages without having to copy all the information in the entire hold
> file at once.

> I know that I can do this by using an SP-EDIT hf# into a "session"
> file and have each page accessible via page0001, page0002, page0003
> etc.  But I'd much rather use the peqs file as the backend database.
> (It'll save me some logic in the front end, cleaning up after users,
> keeping track of things and stuff).

> -Adam


 
 
 

d3 printing a specific page only / max pages

Post by ashel.. » Wed, 30 Apr 2003 03:55:31


Thank you for the reply.  I see a problem with this solution when
attempting to use this on 1000-2000+ page hold files.  It'd be fine if
this was a dedicated d3 server but this has 300-500 users logged in.
Not sure how d3 deals with ram but doing a read/dcount on this data is
not really prefereable.

Thanks for the char(12)/matparse tip though

-Adam

On Mon, 28 Apr 2003 13:37:11 -0500, "Robert Herbin"


>I don't know of any TCL commands to do this, but what you want to do is
>quite easy using Basic.

>To determine the number of pages in a hold file:

>EQU FF TO CHAR(12) ; * FORM FEED
>OPEN 'PEQS' TO PEQS.FV ELSE STOP 201,'PEQS'
>READ REC FROM PEQS.FV,HOLD.ENTRY THEN
>  NBR.PGS = DCOUNT(REC,CHAR(12))
>END ELSE
>  NBR.PGS = 0
>END

>To print a specific page in a hold file, I would do as follows:

>* ASSUMPTION, WE WANT TO PRINT PAGE N
>DIM REC.DIM(NBR.PGS) ; * ALREADY DETERMINED NBR.PGS AS ABOVE
>MATPARSE REC.DIM FROM REC USING FF
>PRINT REC.DIM(N) ; * YOU SAID 'DISPLAY', BUT YOU GET THE IDEA

>This requires the "on the fly" dimensioning of arrays.  I know this works
>with D3, not sure about other pick variants.

>I have found that using the CHAR(12) as the delimiter comes in handy for
>retroactively numbering pages (pg 1 of 10, that sort of thing).

>Robert Herbin

 
 
 

d3 printing a specific page only / max pages

Post by Kevin Powic » Wed, 30 Apr 2003 04:43:44




Quote:> Thank you for the reply.  I see a problem with this solution when
> attempting to use this on 1000-2000+ page hold files.  It'd be fine if
> this was a dedicated d3 server but this has 300-500 users logged in.

You're going to have such problems regardless as there is no way to
only read attributes (A) to (B) of an item.

You may also run into the rare instance where the PEQS file does not
contain an item for the hold file you wish to examine.  In these cases,
you can still print the hold file with SP-EDIT, but the PEQS item
itself is empty.  This was discussed at length in an earlier thread.

Here a links to Google for that thread

http://tinyurl.com/aign
http://tinyurl.com/aigs

Quote:> Not sure how d3 deals with ram but doing a read/dcount on this data is
> not really prefereable.

As already noted above, if you plan on using the single item in the
PEQS file, you're going to have to read it at some point.

--
Kevin Powick

 
 
 

d3 printing a specific page only / max pages

Post by ashel.. » Wed, 30 Apr 2003 06:28:45


My hope was that there was a command at the system level that I could
load with a DATA statement.  I never ever touch the peqs file with a
basic program directly because I don't think it likes it to much.

I explored the manual in depth and found no such command.  I was just
hoping I missed something.

For example, It would be nice if SP-EDIT had a (for use with the 'f'
to file parameter) a way to choose a specific page or page range.
This way from a web page I could say &page=X and stack that onto an
sp-edit command read the output, slapping some xml tags on it) and
give it back to the browser.  This would give me a high speed solution
to my problem(I'd need to know the number of pages though).  

Now I have to first make a call to d3, file all the pages to disk
figure out how many items it just wrote out.  Then get the data for
the first page back to the user.  This method will give me faster
perfomance on subsequent request but now when a user kills his browser
and forgets about this task the hard disk space is still being stolen
by his task.  This means that I'm going to have to have time stamps
(in the item id's) of the filed items and a cleanup process that kills
these items.  Or use a table of session ids and a time stamp that gets
parsed for a level of inactivity.

It would be a more programming friendly task if these two o/s level
commands/information were available to my program.  

Using pick as a back end is a pain-in-da-bu**.  Flame Away.  

-Adam





>> Thank you for the reply.  I see a problem with this solution when
>> attempting to use this on 1000-2000+ page hold files.  It'd be fine if
>> this was a dedicated d3 server but this has 300-500 users logged in.

>You're going to have such problems regardless as there is no way to
>only read attributes (A) to (B) of an item.

>You may also run into the rare instance where the PEQS file does not
>contain an item for the hold file you wish to examine.  In these cases,
>you can still print the hold file with SP-EDIT, but the PEQS item
>itself is empty.  This was discussed at length in an earlier thread.

>Here a links to Google for that thread

>http://tinyurl.com/aign
>http://tinyurl.com/aigs

>> Not sure how d3 deals with ram but doing a read/dcount on this data is
>> not really prefereable.

>As already noted above, if you plan on using the single item in the
>PEQS file, you're going to have to read it at some point.

 
 
 

d3 printing a specific page only / max pages

Post by Kevin Powic » Wed, 30 Apr 2003 07:12:43




Quote:> I never ever touch the peqs file with a
> basic program directly because I don't think it likes it to much.

Not really sure what you mean by this.  In what way does the PEQS file
not like being "touched" by a BASIC program.

Quote:> For example, It would be nice if SP-EDIT had a (for use with the 'f'
> to file parameter) a way to choose a specific page or page range.

AFAIK, It doesn't.

Quote:> Now I have to first make a call to d3, file all the pages to disk
> ...but now when a user kills his browser
> and forgets about this task the hard disk space is still being stolen
> by his task.

Welcome to stateless programming.

Quote:> Using pick as a back end is a pain-in-da-bu**.  Flame Away.

Like any database, it has its strengths and weaknesses.

--
Kevin Powick

 
 
 

d3 printing a specific page only / max pages

Post by Robert Herbi » Wed, 30 Apr 2003 07:49:45


I cannot really address all of your observations here without seeing the
application in more detail, but I have the following observations, which
follow in line

Robert Herbin


Quote:> My hope was that there was a command at the system level that I could
> load with a DATA statement.  I never ever touch the peqs file with a
> basic program directly because I don't think it likes it to much.

The PEQS file works just as reliably as any other file.

Quote:> I explored the manual in depth and found no such command.  I was just
> hoping I missed something.

> For example, It would be nice if SP-EDIT had a (for use with the 'f'
> to file parameter) a way to choose a specific page or page range.
> This way from a web page I could say &page=X and stack that onto an
> sp-edit command read the output, slapping some xml tags on it) and
> give it back to the browser.  This would give me a high speed solution
> to my problem(I'd need to know the number of pages though).

I am virtually certain that this does not exist.

Quote:> Now I have to first make a call to d3, file all the pages to disk
> figure out how many items it just wrote out.  Then get the data for
> the first page back to the user.  This method will give me faster
> perfomance on subsequent request but now when a user kills his browser
> and forgets about this task the hard disk space is still being stolen
> by his task.  This means that I'm going to have to have time stamps
> (in the item id's) of the filed items and a cleanup process that kills
> these items.  Or use a table of session ids and a time stamp that gets
> parsed for a level of inactivity.

I am guessing that there is an existing program that generates this
printout, and you want to grab this output and display it in a browser.  I
think the overhead required to parse the pages that the user wants to see is
no big deal.  The resources required to generate a large report, on the
other hand, can be significant.  If it is possible to index the data, then
perhaps you can build the information a page at a time, thereby eliminating
the creation of the large report and subsequent parsing of individual pages.
You migth even be able to call the existing program with a select list you
generated from your index, and perhaps you could run it with a NOPAGE method
so that it only creates one page.

Quote:> It would be a more programming friendly task if these two o/s level
> commands/information were available to my program.

> Using pick as a back end is a pain-in-da-bu**.  Flame Away.

My proposal, if feasible, is something of a pain in the rear to implement
too.  Programming gets complicated sometimes.
> -Adam





> >> Thank you for the reply.  I see a problem with this solution when
> >> attempting to use this on 1000-2000+ page hold files.  It'd be fine if
> >> this was a dedicated d3 server but this has 300-500 users logged in.

> >You're going to have such problems regardless as there is no way to
> >only read attributes (A) to (B) of an item.

> >You may also run into the rare instance where the PEQS file does not
> >contain an item for the hold file you wish to examine.  In these cases,
> >you can still print the hold file with SP-EDIT, but the PEQS item
> >itself is empty.  This was discussed at length in an earlier thread.

> >Here a links to Google for that thread

> >http://tinyurl.com/aign
> >http://tinyurl.com/aigs

> >> Not sure how d3 deals with ram but doing a read/dcount on this data is
> >> not really prefereable.

> >As already noted above, if you plan on using the single item in the
> >PEQS file, you're going to have to read it at some point.

 
 
 

d3 printing a specific page only / max pages

Post by ashel.. » Wed, 30 Apr 2003 08:15:27






>> I never ever touch the peqs file with a
>> basic program directly because I don't think it likes it to much.

>Not really sure what you mean by this.  In what way does the PEQS file
>not like being "touched" by a BASIC program.

I've seen it lock up a program when trying to read it if someone is
changing attributes (printing it) and stuff.  I don't believe its
meant to be read in by basic programs but rather pick itself.  The
fact that you can access it via TCL and databasic is a inheriant
feature of the file system structure of pick but probably shouldn't be
explored.  I could be completely wrong though.  To me it seems like a
"system" file and shouldn't be touched.

Quote:

>> For example, It would be nice if SP-EDIT had a (for use with the 'f'
>> to file parameter) a way to choose a specific page or page range.

>AFAIK, It doesn't.

No, it doesn't :(

Quote:

>> Now I have to first make a call to d3, file all the pages to disk
>> ...but now when a user kills his browser
>> and forgets about this task the hard disk space is still being stolen
>> by his task.

>Welcome to stateless programming.

Hehe.   Just trying to simplify a certain task.  Minimizing processes
running.  I don't have a generic routine to deal with large amounts of
data when using it through a web interface to d3.  Most of the data
for my web interface gets passed all the way to the web server leaving
no trace on d3 behind except for some logs.  

-Adam

 
 
 

d3 printing a specific page only / max pages

Post by ashel.. » Wed, 30 Apr 2003 08:34:16




>> My hope was that there was a command at the system level that I could
>> load with a DATA statement.  I never ever touch the peqs file with a
>> basic program directly because I don't think it likes it to much.

>The PEQS file works just as reliably as any other file.

Hmm.  Maybe I have heard wrong.
Quote:

>> I explored the manual in depth and found no such command.  I was just
>> hoping I missed something.

>> For example, It would be nice if SP-EDIT had a (for use with the 'f'
>> to file parameter) a way to choose a specific page or page range.
>> This way from a web page I could say &page=X and stack that onto an
>> sp-edit command read the output, slapping some xml tags on it) and
>> give it back to the browser.  This would give me a high speed solution
>> to my problem(I'd need to know the number of pages though).

>I am virtually certain that this does not exist.

It doesn't seem as such but it existence I'm sure would be a useful
feature for more than this application.  Too bad.
Quote:

>> Now I have to first make a call to d3, file all the pages to disk
>> figure out how many items it just wrote out.  Then get the data for
>> the first page back to the user.  This method will give me faster
>> perfomance on subsequent request but now when a user kills his browser
>> and forgets about this task the hard disk space is still being stolen
>> by his task.  This means that I'm going to have to have time stamps
>> (in the item id's) of the filed items and a cleanup process that kills
>> these items.  Or use a table of session ids and a time stamp that gets
>> parsed for a level of inactivity.

>I am guessing that there is an existing program that generates this
>printout, and you want to grab this output and display it in a browser.  I
>think the overhead required to parse the pages that the user wants to see is
>no big deal.  The resources required to generate a large report, on the
>other hand, can be significant.  If it is possible to index the data, then
>perhaps you can build the information a page at a time, thereby eliminating
>the creation of the large report and subsequent parsing of individual pages.
>You migth even be able to call the existing program with a select list you
>generated from your index, and perhaps you could run it with a NOPAGE method
>so that it only creates one page.

Filing it with the no page option could create a very very large item
(probably on the FSI if you are going to do it this way) but any
applcation accessing this file would then have to read this item in
and do something with it.  

I think the solution is to use the SP-EDIT/FILE option because this
way you already have each page of data separated into its individual
item.  A processs that would clean this up is easy to implement, could
run at the start of each request to the discussed process, a batch
program on a timer, once a day at night, whatever.  Not too
complicated.  Its just dangerous because multiple users with a bunch
of browsers open could potentially really "pump" (can i use the world
pump?) a file.  Some control mechanisms could be put in place to
monitor disk usage on a per user basis (which would require another
database keeping track of active sessions / user id/ session id/job
id) but this could be done away with if i didn't have to duplicate the
data in the PEQS file.  

And although, it seems that i CAN read in the PEQS file items
directly, I'm not sure I want to read in a 2000 page report into
memory with a basic READ statement.  Are you guys doing this?  What is
your hardware platform?

-Adam

 
 
 

d3 printing a specific page only / max pages

Post by Kevin Powic » Wed, 30 Apr 2003 09:44:45




Quote:> >> I never ever touch the peqs file with a
> >> basic program directly because I don't think it likes it to much.
> I don't believe its
> meant to be read in by basic programs but rather pick itself.  The
> fact that you can access it via TCL and databasic is a inheriant
> feature of the file system structure of pick but probably shouldn't be
> explored.

Actually, it really hasn't been that long since Pick "opened up" the
spooler so that one could see it as a regular file.  For many years,
hold files were something that programmers didn't really have access
to.  I believe this change was, in part, intended to give developers
more flexibility.

Quote:>  To me it seems like a
> "system" file and shouldn't be touched.

One should take care with any system file, but how is reading it going
to change/hurt anything?

Quote:> Just trying to simplify a certain task.  Minimizing processes
> running.  I don't have a generic routine to deal with large amounts of
> data when using it through a web interface to d3.

The nature of web interfaces and thin clients in general dictate a
different way of handling data.  Certainly one would not want to send
megabytes of data to a thin client, so I understand why you want to be
able to "page" your hold file results.  The problem is not unique and I
believe there are options.

--
Kevin Powick

 
 
 

d3 printing a specific page only / max pages

Post by Homer L. Haze » Wed, 30 Apr 2003 11:09:18


Greetings,

I don't know if somebody mentioned this yet or not, but in the days of old
the SP-EDIT command had a F copy feature that would allow you to put
the item into another Pick item.  I think somebody mentioned this.

What they might not have mentioned was that for every form feed in the
PEQS file, it created a new name for your data item.  Thus if you had
a 10 page report, and you responded with the filename of FOOBAR
and the item name of ITEM.  (YES - THAT'S A PERIOD AFTER THE WORD ITEM)

Then PICK would put the first page in ITEM., the second page in ITEM.0001,
the third page in ITEM.0002, etc.

You can then open this local spool file and directly read the page you want.

You have to fiddle with the page number to get it correct.  You may also
have
to remove some RUNOFF stuff that PICK shoves in the file items.

Good Luck,

Larry Hazel




> >> My hope was that there was a command at the system level that I could
> >> load with a DATA statement.  I never ever touch the peqs file with a
> >> basic program directly because I don't think it likes it to much.

> >The PEQS file works just as reliably as any other file.
> Hmm.  Maybe I have heard wrong.

> >> I explored the manual in depth and found no such command.  I was just
> >> hoping I missed something.

> >> For example, It would be nice if SP-EDIT had a (for use with the 'f'
> >> to file parameter) a way to choose a specific page or page range.
> >> This way from a web page I could say &page=X and stack that onto an
> >> sp-edit command read the output, slapping some xml tags on it) and
> >> give it back to the browser.  This would give me a high speed solution
> >> to my problem(I'd need to know the number of pages though).

> >I am virtually certain that this does not exist.
> It doesn't seem as such but it existence I'm sure would be a useful
> feature for more than this application.  Too bad.

> >> Now I have to first make a call to d3, file all the pages to disk
> >> figure out how many items it just wrote out.  Then get the data for
> >> the first page back to the user.  This method will give me faster
> >> perfomance on subsequent request but now when a user kills his browser
> >> and forgets about this task the hard disk space is still being stolen
> >> by his task.  This means that I'm going to have to have time stamps
> >> (in the item id's) of the filed items and a cleanup process that kills
> >> these items.  Or use a table of session ids and a time stamp that gets
> >> parsed for a level of inactivity.

> >I am guessing that there is an existing program that generates this
> >printout, and you want to grab this output and display it in a browser.
I
> >think the overhead required to parse the pages that the user wants to see
is
> >no big deal.  The resources required to generate a large report, on the
> >other hand, can be significant.  If it is possible to index the data,
then
> >perhaps you can build the information a page at a time, thereby
eliminating
> >the creation of the large report and subsequent parsing of individual
pages.
> >You migth even be able to call the existing program with a select list
you
> >generated from your index, and perhaps you could run it with a NOPAGE
method
> >so that it only creates one page.

> Filing it with the no page option could create a very very large item
> (probably on the FSI if you are going to do it this way) but any
> applcation accessing this file would then have to read this item in
> and do something with it.

> I think the solution is to use the SP-EDIT/FILE option because this
> way you already have each page of data separated into its individual
> item.  A processs that would clean this up is easy to implement, could
> run at the start of each request to the discussed process, a batch
> program on a timer, once a day at night, whatever.  Not too
> complicated.  Its just dangerous because multiple users with a bunch
> of browsers open could potentially really "pump" (can i use the world
> pump?) a file.  Some control mechanisms could be put in place to
> monitor disk usage on a per user basis (which would require another
> database keeping track of active sessions / user id/ session id/job
> id) but this could be done away with if i didn't have to duplicate the
> data in the PEQS file.

> And although, it seems that i CAN read in the PEQS file items
> directly, I'm not sure I want to read in a 2000 page report into
> memory with a basic READ statement.  Are you guys doing this?  What is
> your hardware platform?

> -Adam

 
 
 

d3 printing a specific page only / max pages

Post by Tony Gravagn » Wed, 30 Apr 2003 12:18:33


Responses below for Adam, just as an add-on to Kevin's.
After writing this I noticed other posts were made to the thread,
sorry if the comments are redundant.




>> I never ever touch the peqs file with a
>> basic program directly because I don't think it likes it to much.

>Not really sure what you mean by this.  In what way does the PEQS file
>not like being "touched" by a BASIC program.

I play with peqs all the time.  Never seems fragile to me.

Quote:>> For example, It would be nice if SP-EDIT had a (for use with the 'f'
>> to file parameter) a way to choose a specific page or page range.

>AFAIK, It doesn't.

No matter how you slice it, you're going to have to generate data and
then parse through it for delimiters.  Either the system does it or
you do it with BASIC.  So even if there were another option on sp-edit
the same work is still being done.

This "let someone else do it" concept is called the NIMBY principle,
for "Not In My Back Yard".  It's usually applied to putting prisons or
power plants around residential areas, (anyone play SimCity?) but it
applies a lot to code too - just because we delegate a chore to some
other process doesn't mean it'll be any more performant or attractive
a solution.  But I digress, and then some.

Hmm, now that I think about this, if you really want to get creative,
you can use a shared printer rather than a hold file, send the output
through a filter which parses the data and leaves it in the native
file system.  At least this will be done on the fly and not live.  You
can then grab the pages you need with no parsing at all.

Quote:>> Now I have to first make a call to d3, file all the pages to disk
>> ...but now when a user kills his browser
>> and forgets about this task the hard disk space is still being stolen
>> by his task.

>Welcome to stateless programming.

Agreed.  The real question is, why are you generating (potentially)
1000-2000 pages of data for a user who may not stick around for the
results?  A better solution is first to use indexing and generate only
the data that the user really wants.  Second, give the user some form
of entertainment while the report is being generated so that they
don't go away.  For a web interface you can do this with polling
frames (use meta refresh tag), shockwave/flash, java, or some other
interface more intelligent than plain HTML.

Another possible solution (depending on how diverse your needs are) is
to generate the x-thousand page document once and then somehow index
the report itself so that user queries will allow you to point
directly into the report.  This is compared to generating a new report
for every request.  This creates a near-line state engine (neither
on-line nor off-line) which you may want to offload to another
query-only system.  I don't like this particular idea but there are
many ways to skin these cats.

If you have impatient users, you'll absolutely need to generate your
reports asynchronously anyway, lest someone hang all your processes
with dead requests.

Quote:>> Using pick as a back end is a pain-in-da-bu**.  Flame Away.

>Like any database, it has its strengths and weaknesses.

I don't see this as being a weakness, bad planning for user
requirements and poor design are going to be a pain no matter what
tools you use.  Adam, you said yourself:
Quote:> It'll save me some logic in the front end, cleaning up after
> users, keeping track of things and stuff.

If you're using Pick as a back-end then technically it's not
responsible for the user interface.  Make up your mind (no offense
intended), but the functions have to be written "somewhere".

Tony

 
 
 

d3 printing a specific page only / max pages

Post by Jeffrey Kaufma » Wed, 30 Apr 2003 23:57:04


I am surprised none of us 'old timers' posted this SP-EDIT method. Maybe
someone did and I missed it. Anyway, this is how we did it before the peqs
file was made accessible.

JOB.NO=SYSTEM(20)
SP.ID="SPOOL.ID.":PORT.NO
AM=CHAR(254)
DATA "S":AM:"F":AM:"SUSPENSE":AM:SP.ID:AM:"N"
ECHO OFF
EXECUTE 'SP-EDIT ':JOB.NO
ECHO ON

The above code writes the spooler entry into my SUSPENSE file, a separate
record per page. The first line of each record has some control code and can
be deleted. The last line contains the id of the next record. Simply read
the desired record from a basic program and send it to the printer.

I hope this works for you.
Jeff
--

Jeffrey Kaufman
Key Data Systems Group
www.keydata.us
559-432-3832
559-432-4657 fax


> My hope was that there was a command at the system level that I could
> load with a DATA statement.  I never ever touch the peqs file with a
> basic program directly because I don't think it likes it to much.

> I explored the manual in depth and found no such command.  I was just
> hoping I missed something.

> For example, It would be nice if SP-EDIT had a (for use with the 'f'
> to file parameter) a way to choose a specific page or page range.
> This way from a web page I could say &page=X and stack that onto an
> sp-edit command read the output, slapping some xml tags on it) and
> give it back to the browser.  This would give me a high speed solution
> to my problem(I'd need to know the number of pages though).

> Now I have to first make a call to d3, file all the pages to disk
> figure out how many items it just wrote out.  Then get the data for
> the first page back to the user.  This method will give me faster
> perfomance on subsequent request but now when a user kills his browser
> and forgets about this task the hard disk space is still being stolen
> by his task.  This means that I'm going to have to have time stamps
> (in the item id's) of the filed items and a cleanup process that kills
> these items.  Or use a table of session ids and a time stamp that gets
> parsed for a level of inactivity.

> It would be a more programming friendly task if these two o/s level
> commands/information were available to my program.

> Using pick as a back end is a pain-in-da-bu**.  Flame Away.

> -Adam





> >> Thank you for the reply.  I see a problem with this solution when
> >> attempting to use this on 1000-2000+ page hold files.  It'd be fine if
> >> this was a dedicated d3 server but this has 300-500 users logged in.

> >You're going to have such problems regardless as there is no way to
> >only read attributes (A) to (B) of an item.

> >You may also run into the rare instance where the PEQS file does not
> >contain an item for the hold file you wish to examine.  In these cases,
> >you can still print the hold file with SP-EDIT, but the PEQS item
> >itself is empty.  This was discussed at length in an earlier thread.

> >Here a links to Google for that thread

> >http://tinyurl.com/aign
> >http://tinyurl.com/aigs

> >> Not sure how d3 deals with ram but doing a read/dcount on this data is
> >> not really prefereable.

> >As already noted above, if you plan on using the single item in the
> >PEQS file, you're going to have to read it at some point.

 
 
 

d3 printing a specific page only / max pages

Post by ashel.. » Thu, 01 May 2003 01:32:42


On Mon, 28 Apr 2003 20:18:33 -0700, Tony Gravagno


>Responses below for Adam, just as an add-on to Kevin's.
>After writing this I noticed other posts were made to the thread,
>sorry if the comments are redundant.




>>> I never ever touch the peqs file with a

>This "let someone else do it" concept is called the NIMBY principle,
>for "Not In My Back Yard".  It's usually applied to putting prisons or
>power plants around residential areas, (anyone play SimCity?) but it
>applies a lot to code too - just because we delegate a chore to some
>other process doesn't mean it'll be any more performant or attractive
>a solution.  But I digress, and then some.

Don't get me wrong here.  I was hoping for a faster "compiled" process
for what I wanted to do.  I figured code compiled for the pick
platform would probably run faster than a simple flashed based
solution.

- Show quoted text -

Quote:

>Hmm, now that I think about this, if you really want to get creative,
>you can use a shared printer rather than a hold file, send the output
>through a filter which parses the data and leaves it in the native
>file system.  At least this will be done on the fly and not live.  You
>can then grab the pages you need with no parsing at all.

>>> Now I have to first make a call to d3, file all the pages to disk
>>> ...but now when a user kills his browser
>>> and forgets about this task the hard disk space is still being stolen
>>> by his task.

>>Welcome to stateless programming.

>Agreed.  The real question is, why are you generating (potentially)
>1000-2000 pages of data for a user who may not stick around for the
>results?  A better solution is first to use indexing and generate only
>the data that the user really wants.  Second, give the user some form
>of entertainment while the report is being generated so that they
>don't go away.  For a web interface you can do this with polling
>frames (use meta refresh tag), shockwave/flash, java, or some other
>interface more intelligent than plain HTML.

Yeah, java script and divs are your friend.
Quote:

>Another possible solution (depending on how diverse your needs are) is
>to generate the x-thousand page document once and then somehow index
>the report itself so that user queries will allow you to point
>directly into the report.  This is compared to generating a new report
>for every request.  This creates a near-line state engine (neither
>on-line nor off-line) which you may want to offload to another
>query-only system.  I don't like this particular idea but there are
>many ways to skin these cats.

>If you have impatient users, you'll absolutely need to generate your
>reports asynchronously anyway, lest someone hang all your processes
>with dead requests.

I can probably trust my users, and I can also embed a splash screen to
the effect: close this while processing and your computer will catch
fire (which they will believe) but relying on anything from the user
isn't something i'm in practice of doing.

The reports for this project will be already generated.  This is an
online hold file viewer.  We have a hold file viewer written in basic.
I'm just porting it to the web cause thats what users know how to use.

Quote:

>>> Using pick as a back end is a pain-in-da-bu**.  Flame Away.

>>Like any database, it has its strengths and weaknesses.

>I don't see this as being a weakness, bad planning for user
>requirements and poor design are going to be a pain no matter what
>tools you use.  Adam, you said yourself:
>> It'll save me some logic in the front end, cleaning up after
>> users, keeping track of things and stuff.
>If you're using Pick as a back-end then technically it's not
>responsible for the user interface.  Make up your mind (no offense
>intended), but the functions have to be written "somewhere".

I started this thread it was simply a hope that somewhere in pick was
implemented (it isn't) a Print page x to y function some where.  It
just seems useful. Like i have a hold file i've reviewed it (on
screen) And i've found the information I need in it.  Now I want to
print page x or page x to y or page x, y, z.  

One more note:  The only front end that isn't programmed in pick (d3)
is the menu macros and tcl.  Of course the front end is going to be
written.  All pick front ends are.  (Excluding mvBase typed stuff).

Heh

Thanks for all the discussion though.  It is safe to say that there is
no print specific page option in d3. :)

-Adam

 
 
 

d3 printing a specific page only / max pages

Post by Jeffrey Kaufma » Thu, 01 May 2003 05:00:17


I posted a method of printing a single page this morning. Did you see the
post?

--

Jeffrey Kaufman
Key Data Systems Group
www.keydata.us
559-432-3832
559-432-4657 fax


Quote:> Heh

> Thanks for all the discussion though.  It is safe to say that there is
> no print specific page option in d3. :)

> -Adam

 
 
 

1. how to save specific page (records of a page) to a stream object

Hi

I am trying to use the ADO component, in order to retrieve records, of
specific page at a time, and to send it to the client as a XML.

example:

  Dim strm As New ADODB.Stream
  Dim rstEmployees As ADODB.Recordset

   rstEmployees.CacheSize = 5
   rstEmployees.PageSize = 5

    rstEmployees.Open strSQL, strCnxn, CursorTypeEnum.adOpenStatic,
adLockReadOnly, adCmdTable

      rstEmployees.AbsolutePage = 2
      rstEmployees.Save strm, PersistFormatEnum.adPersistXML

I was expecting to find in the strm object only 5 records, but surprisingly
I sow all the table records!

What did i do wrong?!

Thanks a lot

Racheli

2. 'SUSPECT' Database Problem

3. How to print page's footer in specific location

4. can I see the procedures in a package thru SQLPLUS???

5. printing specific pages from Adobe in Foxpro

6. from 4.0 to Newer? Any chance? Experiences

7. Page Printing Muti-Page Forms

8. (ODBC) i cant add but i can delete?

9. Printing Problems When Page Height < Page Width

10. pdox4.5 m-page forms:printing 2nd page

11. Print MSDN articles exceeds printed page width

12. Printing a selected page from print preview