I can give you a few tips, however I am a little confused on exactly your question.
First you must become familiar with the RPE and global RPE.
The RPE (runtime program environment) is stored at the MQL level as a stack for variables that can be passed from the Matrix system to your programs or between wizard frames, or in the case of the global RPE, between programs.
From within TCL, one can access RPE vars by:
set myvar [mql get env VARNAME] set myvar [mql get env global VARNAME]
To set RPE vars from TCL:
mql set env VARNAME "some value" mql set env global VARNAME "some value"
The local RPE persists for the term of the execution of the current INVOCATION, but goes away after runtime. The global RPE persists beyond and between INVOCATIONs of the interpreter.
Hence, the local RPE is most used for: - system sets values for method invocations for such things as TYPE, NAME, REVISION, INVOCATION, etc. - passing user custom vars from/to wizard frames and wizard CODE
The global RPE is used for persistant values between program executions. So if progA gets some info and then later in the MATRIX session progB wants to do some thing with it, the user would write those values to the global RPE. HOWEVER, such persists only for the Matrix session and IS NOT part of any db record, therefore is lost when Matrix exists.
[NOTE - I have created a product that I call trigger frameworks and wizard frameworks to both do this more elegently and also I employ what I call "IPM" (persistent InterProcess Messaging services) which allow for creating persistent (beyond session and global RPE) questions and responses to varied data acquisition methods such as wizards, etc. Messages are classified and identified by a special PID. Then when message retrieval is requested the PID and message class is used to retrieve either queries to be posed to the user, and/or their response. Generally the PID is something constructive from the environment, such as TNR, user name, etc. So ... a user could provide part of the info to a wizard, quit matrix, and come back tomorrow and finish the wizards inquiry without re-entering everything again. This has greater implications also relative to workflow, etc.]
An alternative to the above but a little "clunky" is to create a reproducible PID, and puts from TCL records to an ASCII file. Later, the PID would be reconstructed and the text file read to reconstruct the data in session.
Regarding formating your data, you may want to look into tables. You can configure a table so that the data will appear in the order that you want the records to be structured for the output file. Then to generate the output file, do "evaluate table ..." and specifiy a record delimeter. This can then be read into MSAccess, MSExcel, etc. as delimeted data.
Another idea is to use TCL to build an HTML formatted file for your data. then the report, etc. can be viewed by IE or Netscape. So, ... the file checked into the businessobject would be an HTML file, and when the user d-clicks the matrix businessobject, it will "view" the file content by checkout and then lauch the windows associated application, in this case the browser.
Launching programs in Matrix can take different forms. You can issue "mql exec prog ...", however make sure that the program is DEFERED and that it is NOT a wizard.
As of Matrix 9.5.x.x there is the "appl wizard ..." application dialog command. this is very helpful, and can bus used the "chain" wizards together. Some restrictions however, is that INVOCATION can not be CHECK or OVERRIDE from a trigger. ACTION can fire it, but the ACTION trigger program must be DEFERED. I've attempted workarounds, but you introduce instabilities into the application.
Launching a program as a METHOD of a businessobject, one can: execute businessobject ...
Wizard related programs such as: prologue, epilogue, load, validate, button, observer, and CODE are all native invocations, however CODE can in turn execute "appl wizard ..." to get a cascading effect.