Others may have given you most of the answers that you want, but you should
check out:
   Handling COBOL limitations with multithreading
at:
   http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/4.4.6 

and
   THREAD
at
   http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.54 

and
  "Comparison of WORKING-STORAGE and LOCAL-STORAGE"
at
   http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.1.3.2 

and 
  "Sharing data in recursive or multithreaded programs"
at
   http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/1.1.3.3.3 



 * * * * * *

In general, I think that when you convert (upgrade) to Enterprise COBOL, you
will find that (as long as you keep using an Assembler driver to start the
threads), that you can have "supported" COBOL applications that do what you
want.

"Michael Knigge" <[email protected]> wrote in message
news:<[email protected]>...
> All,
> 
> once upon the time, we had to write an application (in VS COBOL II) that
>   uses subtasks.
> 
> Because this old COBOL release did not support subtasks, we did a trick:
> We've attached from an ASM driver a little ASM stub that did just one
> thing: call the wanted COBOL prog.
> 
> We had to link all COBOL-Modules statically to get all this stuff
> working. The COBOL progs are also using some ASM Subs for some special
> things (i. e. doing a GETMAIN, FREEMAIN, STIMERM and so on). They are
> also statically linked. So the initial ATTACH attaches a really big
thing...
> 
> 
> Now we are just about 13 years later and I have to convert this
> application. We want to use Enterprise COBOL and dynamic CALLs.
> 
> 
> Now..... I guess all the COBOL-Stuff will work pretty well (I guess that
> the WOKING-STORAGE gets getmained for every new copy of the COBOL-Prog
> within each subtask).
> 
> But I wonder how to migrate the ASM-Subs nearly painless.... I could
> rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just
> using REUS=NONE would do the same job...
> 
> So bring it to a question: What is the "scope" of the REUS-Option?
> (Sub)Task-Level? Then using "REUS=NONE" would bring up a new copy of the
> ASM-Stubs for every Subtask - just what I need.... I don't care for the
> "wasted" memory because the ASM-Subs are mostly rather small (and well,
> today they are all statically linked together with some really big
> COBOL-Subs)....
> 
> 
> Thank you for hints....
> 
> 
> Bye,
> Michael
> 
> 
> 
> -- 
> Mit freundlichen Grüßen
> 
> Michael Knigge
> Entwicklung
> 
> 
> S.E.T. Software GmbH
> Lister Straße 15
> 30163 Hannover
> 
> Tel.  +49 511/3 97 80-23
> Fax   +49 511/3 97 80-65
> [email protected]
> 
> Handelsregister: HRB52778 Amtsgericht Hannover
> Geschäftsführer: Till Dammermann, Klaus Stöhr
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to