selection for report without selection table

[Bruce Easton]

Mark wrote Thursday, July 24, 2008 3:11 PM:
> 
> Confusious (Bruce Easton) say:
> > (inline reponses -Bruce - STN, Inc.)
> 
> Ditto.
> 
> > As per my last response, you can substitute interactive input with
> > hard-coding or with values supplied via -r+ at pm, etc. as necessary.
> 
> Negatory.  Security issue; tainted input near a command line--which OG
> won't allow anyway.  That's why I use a file to store data and have
> processing parse that file.  Same result, possible under OG, secure.

Yeah - here I was still talking about those output requests being 
issued from within a controlling clerk process - not directly by OG.

> 
> > You should be able to use FORM and FORMM to print from the
> > same clerk session that you are using as a control session, but
> 
> I said I was using report, not clerk.  I'll have to use subsequent
> commands.  But you just answered the question, although someone 
> gave me the
> idea I should be able to just use -f instead of -fp, do my usual 
> stuff, and
> lookup, populate dummy fields, and use print.  Cleaner--if it works.

Yes the print command.  but hopefully you're not also trying 
to control sorting based on user input.  

> 
> > Yeah, but if you're trying to stay in the same clerk session
> > (I'm assuming all from @menu), then why not just control your
> > filtering there inside lookup loops rather than doing I/O to
> > another file?
> 
> You must have forgotten my methodology:

Sorry - I did forget. 

> 
> /appl/fp/dreport cgi_control -u -sr %n -fp proc_table >/dev/null 2>&1
> 
> I think I can just use an actual cloned format with dummies, do my
> population from lookup, and use print.  Yes?

I think so.  So your capturing (via web) user selection args in one 
OG dreport process, and then running the next OG dreport 
process as a version of an existing char-based report?  Maybe you 
could store the selection parameters from the first process to 
be read (as opposed to retrieving passed arguments) so that the 
selection processing can still get them and do the job without 
having to write out an intermediate file?

> 
> > Oh - so you are doing PDF generation at the same time.
> > Well if you use dreport with -v, then there should be no need to use
> > a limiting file - take out interactive and replace with values
> > from @pm, etc. passed from the clerk controlling process to get
> > the proper selection done.  Output finished report to a file and
> > then run pdf processor on that file to produce pdf.
> 
> How are you doing @pm work in OneGate with dynamic values without using
> system?  That's not possible.  It's designed to prevent it--commands are
> immutable.  You'd have to system() to do that, which throws a wrench in
> user counting.

No - in that type of case I do use system.

> 
> mark->