× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



just pushing this conversation to the mailing list for archival...

Tommy


----- Original Message ----- 
From: Rory Hewitt 
To: Aaron Bartell 
Cc: aaronbartell@xxxxxxxxx ; Mihael.Knezevic@xxxxxxxxxxx ; 
belliott@xxxxxxxxxxxxxxxxxxx ; DTurnidge@xxxxxxxxxxxxxxxxxxxx ; 
tommy@xxxxxxxxxxxxxxx 
Sent: Monday, August 07, 2006 12:16 PM
Subject: Re: Hey...


Aaron,

My thoughts exactly - it's a method I already use (as do you, I believe). Using 
the QleGetExp() procedure and (possibly) a set of hard-coded values for the 
'default' values, like XML.

Something like this pseudo-code during the initialization, perhaps:

select;
  when parameter.outputmethod = '*XML';
    outputter.procptr = %paddr( OutputToXml );
    outputter.file = parameter.ifsfile;
  when parameter.outputmethod = '*PRINT';
    outputter.procptr = %paddr( OutputToPrint );
    outputter.file = parameter.file;
  when parameter.outputmethod = '*DATABASE';
    outputter.procptr = %paddr( OutputToFile );
    outputter.file = parameter.file;
    outputter.library = parameter.library;
    outputter.member = parameter.member;
  other;
    // look up parameter.outputmethod in xref file
    // get name of procedure related to output method
    // set outputter.procptr using QleActBndPgm() and
    // QleGetExp() on the procedure name.
endsl;

It would be up to the user to supply (in an xref file or perhaps simply in the 
parameter structure) the details of the outputter procedure (which *SRVPGM it's 
in, its name etc.). The only requirement would be that it would have to be 
written using the same standard parameters which would be sent to the default 
outputters. 

So they could have something like the following the the xref file (to output to 
an internal system they use):

Method     ProcName                Service program

*INTSYS    OutputToOurSystem       OURSRVPGM

Or maybe I'm getting ahead of myself at this point... Too caught up in details. 
At any rate, this should be fairly easy to backpatch into what we already have, 
I think.

Rory
 
On 8/7/06, Aaron Bartell <aaron@xxxxxxxxxxxxxxx> wrote: 
  That outputter method plugin sounds great to me. We could use procedure 
pointers to make that REALLY easy to separate out plugins.

  Thoughts about using procedure pointers?




  -----Original Message-----
  From: Rory Hewitt < roryhewitt@xxxxxxxxx>
  To: Aaron Bartell <aaronbartell@xxxxxxxxx>
  CC: Knezevic, Mihael < Mihael.Knezevic@xxxxxxxxxxx>; Bob Elliott < 
belliott@xxxxxxxxxxxxxxxxxxx>; Dave Turnidge <DTurnidge@xxxxxxxxxxxxxxxxxxxx>; 
Me < tommy@xxxxxxxxxxxxxxx>
  Sent: Mon Aug 07 12:24:53 2006
  Subject: Re: Hey...

  As far as Mihael's comment about direct XML output, I'd have to agree - XML 
is no good to me. I'd like to ensure that any output processing is performed in 
such a way that it can be output in any format. 

  My original parser used a single 'interim' output procedure; any 'outputter' 
subprocedure could be defined to receive that output and format it as requested 
- you just pass the interim output procedure a data-structure containing the 
data (which might be a keyword/value or might be a field-name/occurrence-count 
or whatever) and a procedure pointer to the outputter procedure. 

  That system is flexible enough to allow XML output and also direct database 
output, output to a print-file or even display output. It also allows users to 
define their own outputters as plug-ins, since all they need to know is the 
pre-defined parameter format that will be passed to it. 

  Rory

  On 8/7/06, Aaron Bartell <aaronbartell@xxxxxxxxx> wrote:

          >lpex parser: i don't think we will get any source of the parser and 
i don't 
          think we need to.
         
          The reason I suggested this is because we would already be at the 
finish
          line walking up to the awards podium if we were able to get the code 
for
          this.  And as future RPG updates came out we could just plop in the 
latest 
          version of the LPEX parser and we would be able
         
         
          >/free: what would you like to parse in a free block? everything is 
defined
          outside of any free block.
         
          How many times a variable is used for example.  Parse freeform 
comments for
          keywords for another example.
         
          >java: i think java was dropped very early because very few people 
working 
          on the project know java good enough to write it all in java. at 
least that
          was what i interepreted from the comments earlier.
         
          That's a good enough reason for me :-)  I wish I could contribute 
more, but 
          it sounds like we are in the same boat.
         
          Anyways, with the great progress that has been made so far, it may be 
time
          in the near future to do an announcement in the RPG forum and see if 
more 
          interest is generated.
         
          Aaron Bartell
         
          -----Original Message-----
          From: Knezevic, Mihael [ mailto:Mihael.Knezevic@xxxxxxxxxxx]
          Sent: Monday, August 07, 2006 2:11 AM
          To: Aaron Bartell; Bob Elliott; Dave Turnidge; Me; Knezevic, Mihael; 
Rory
          Hewitt
          Subject: AW: Hey... 
         
          i'm still interested in this project but it has moved in a direction 
where
          it becomes unusable to me. for example the direct xml output. i could 
live
          with it but it would be a hard life cause i would have to merge all 
the xml 
          files again and then make some transformation to html. it would be 
much
          easier if the data would be stored in one db table. (don't know why 
it was
          suddenly dropped).
         
          java: i think java was dropped very early because very few people 
working on 
          the project know java good enough to write it all in java. at least 
that was
          what i interepreted from the comments earlier.
         
          lpex parser: i don't think we will get any source of the parser and i 
don't 
          think we need to.
         
          /free: what would you like to parse in a free block? everything is 
defined
          outside of any free block.
         
          time: currently i have a bit less time to spend on this project cause 
there 
          are several other open source projects i'm currently working on. but 
i would
          like to keep the project alive.
         
          my 2 cents.
         
          mihael
         
          -----Ursprüngliche Nachricht----- 
          Von: Aaron Bartell [mailto:aaronbartell@xxxxxxxxx]
          Gesendet: Freitag, 4. August 2006 15:32 
          An: 'Holden Tommy'; 'Adam Glauser'; 'Bob Elliott'; 'Dave Turnidge'; 
'Me';
          Knezevic, Mihael; 'Rory Hewitt'
          Betreff: RE: Hey...
         
          I am just lacking time right now.  Been hit with a whole bunch of 
changes 
          that clients need for software I have written.  This is what is such a
          bummer about open source is that it is like pulling teeth to get 
people to
          contribute.  Of all the open source I have done with stuff on 
          http://mowyourlawn.com I have yet to get code help.  I do get a lot of
          requests for changes and people that find bugs, but nobody helps.  It 
just 
          isn't the world that iSeries developers live in.
         
          With that said, I also disagree with a lot of the approaches that are 
being
          taken - though many of the approaches may have changed by now.  I got 
the 
          feeling that everything being done was starting from scratch and 
existing
          resources weren't being research and utilized as much as they should 
have
          (i.e. there has to be some source code crawler out there written in 
Java 
          that could facilitate most of what we need).  Then there was talk of 
first
          putting the crawled results into a database, I think that was a wrong 
move
          because we were limiting ourselves to horizontal formats. 
         
          On the note of existing things we could use, it would be interesting 
to see
          how far we could get if we approached IBM about some of the LPEX 
parsers
          they have for WDSC.  In reality they have EVERYTHING we would need to 
          intimately parse an RPG source member at any OS level (i.e. I would 
want it
          to be able to parse /FREE format).  The guy to email about this would 
be
          George Farr as he is heading up the division: farr@xxxxxxxxxx  I 
would email
          him but fear I wouldn't have the bandwidth right now to adequately 
follow-up 
          with any response he might provide.
         
          I still wish to be a part of this, but for the foreseeable future I 
am not

          going to be a major role player, Aaron Bartell http://mowyourlawn.com 
< http://mowyourlawn.com>

         

         





As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.