Question How Pass Stream As Parameter

K

KennyAround

Member
Progress Version: 11.x
Progress Platform: Linux, character based
Windows: Windows 8

I am using character based ABL. I have 2 branches of the company, I need to create 10 outputs for each branch for data in the past 10 years with 1 file for 1 year's data.

I thus need to output files to 20 separate streams. i grouped all the output logic into a procedure. My question is how will I be able to pass the stream to this procedure to output to the various streams.

Moreover, this program is run in a special environment which a .I is not allowed. That is, all the codes must be in a single .P program.

Thanks in advance.
 
I got it resolved somehow. Thanks guys.

The file size is about 100 MB to 200 MB each.

solution:
Code: 
define stream sBranchA.
define stream sBranchB.
define var cFile as char extent 20 no-undo.
define var cName as char extent 2 no-undo.
define var i as int no-undo.
define var j as int no-undo.

/* I calculate and switch the output stream to different files */

do i = 5 to 15:
     j = (i - 5) * 2.
     vFile[1 + j]  = "BranchA_20" + string(i,"99") + ".txt".   /* file name will be as BranchA_2005.txt */
     vFile[2 + j] = "BranchB_20" + string(i,"99") + ".txt".
end.

/* now loop through data */
data_loop:
for each ....:
     /* now calculate the output file name for data */
     j = if branchA then 1 else 2.
     i = (year(record_date) - 2005) * 2 + j.

     if vFile[i] <> vName[j] then do: /* switch output file, as data is indexed by date so the switch only occur once for each year */
           if branch = "A" then do:
                  output stream sBranchA close.
                  output stream sBranchA to value (vFile[i])
           end.
           else do: /* do the same for branch B */
                  output stream sBranchB close.
                  output stream sBranchB to value (vFile[i])
           end.

          vName[j] = vFile[i]
     end.

end. /* data loop */
 
For the record, this seems to work and seems to meet the original requirement:

def stream x.
output stream x to /tmp/gt1.
run p(stream x:handle).
output stream x close.
output stream x to /tmp/gt2.
run p(stream x:handle).
output stream x close.

procedure p:
def input param s as handle. /* Voila! */
put stream x "hello".
end.
 
Oops! Not quite. The 'put stream x', DUH, is just referencing the procedure-visible stream defined previously. A good example of why I'd like a 'make procedure-level names invisible inside internal procedures' compiler option. Anyway. I don't have a compiler in front of me, but it's probably possible to rearrange this code slightly to make it work. Apologies for the overly hasty earlier reply.

http://documentation.progress.com/o...ABL/ABL Reference/20dvref-Handles.034.45.html
 
My question about file sizes was that if they weren't too big it would be much more interesting to build them as a LONGCHAR and then just COPY-LOB. No need for streams. :)
 
Also note that passing a stream as a parameter is a strong hint that you should be moving the stream processing into a persistent procedure or object so that the stream handling all happens in one place.
 
this should work:

Code: 
define stream str1.
define variable hstr as handle no-undo.
hstr = stream str1:handle.
output stream str1 to "teststream.txt".
export stream str1 "in main 1".
run teststream.p(input hstr ).
export stream str1 "in main 2".
output stream str1 close.

teststream.p:
define input parameter iphstr as handle no-undo.
export stream-handle iphstr " in sub 1".
 
Thank you Thomas for your comment. While I agree with you generally about keeping things in one place, in this instance I've used a stream to direct error messages to an error log file. Although in this instance my app is trivial, I'm nevertheless sending error messages to the log from several different modules and this seemed like an easy to understand (and easy to implement!) way of doing so. Since error messages will be submitted to the stream asynchronously (system is small but multi-user) I am nevertheless intrigued to see how well Openedge will cope with sharing this stream in terms of fatal embrace issues...but then I'm just an app programmer! Regards, Allan.
 
The stream isn't shared among sessions so "deadly embrace" really doesn't come into play. More likely is that if you have multiple sessions writing to a single log file you will get "blended" log content. IOW lines that are overwriting and interspersing one another. Especially if you open your logs "unbuffered".

If that describes your situation then you might want to consider using buffered output and opening/closing the destination file with every line of output.

Or use LOG-MANAGER
 
And why not send the error message to a common component, preferably an object, and have that component manage the stream ... or whatever you use. Note that with a common, shared error message component you can choose at any time to change the implementation and you only need to touch one place.
 
Thanks for your suggestions Tom and Thomas.

I'd not come into contact with "common components" before.... The modularity is certainly attractive! Still learning after all these years.... :-)

I'd predicted the "interleaved message" problem, but wondered if buffering would cause the contributing processes to freeze... but I guess that's only for a few milliseconds which really doesn't matter for my app...

And I'll have to look up LOG-MANAGER. (This is what happens to old programmers who never got proper training in the first place!)

Best wishes, and thanks again,

Allan.
 
And, I would start exploring OO programming in ABL. It really is the best way to encapsulate logic and shared data.
 
Thanks Tamhas, excellent advice I am sure. However my full time job is to maintain a heritage system which was almost entirely written before OO ABL had really become established by a programmer who left shortly after it was implemented. The system is now theoretically end-of-life and will soon (maybe!) be replaced by a non-Progress alternative, so in the meantime I have to keep this one going until that day arrives... By which time I may well have retired!

Regards, Allan.
 
You must log in or register to reply here.
Back
Top