Farley, Peter x23353 wrote:
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Michael Knigge
Sent: Tuesday, July 07, 2009 6:13 AM
To: [email protected]
Subject: Question about REUS=NONE
<Snipped>
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).
AFAIK, WORKING-STORAGE still only gets created once per COBOL program,
on first call of the COBOL program. I think that what you need to use
is called LOCAL-STORAGE, which is re-allocated on every call.
You need to be careful with dynamic call vs. attaching. Enterprise
COBOL programs can appear in a multitasking environment if they
are compiled with the THREAD option. Each task will have its own
copy of working-storage. COBOL programs cannot do the attach, but
they may be attached.
Otherwise, in a classic dynamic call environment, working-storage
is created once for the first dynamic call of a routine. The values
in working-storage variables remain in their last used state across
subsequent calls unless a) you explicitly reset values or b) the
program has the INITIAL attribute specified on the program-id paragraph.
LOCAL-STORAGE, on the other hand, as Peter points out, is
created fresh each time the routine is entered. You can mix and
match; that is, you can have a working-storage section and a
local-storage section, which can be a useful arrangement sometimes.
If you have a local-storage section, it must appear after any
wokring-storage section and before any linkage section.
However, that is not your only problem. COBOL (even Enterprise-level)
is still NOT guaranteed or warranted by IBM to work in a real
multi-tasking environment. In particular, the output message file,
normally SYSOUT, cannot be shared among subtasks and you still may need
an assembler stub to keep each subtasks's messages displayable
somewhere.
There I must disagree, to a degree :). Compile with THREAD; and
you can set your runtime to include "MSGFILE(ddname,,,ENQ)"; this
should allow multiple tasks to share SYSOUT (although the outputs
are likely to be intermixed!).
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...
You do not need GETMAIN/FREEMAIN subroutines any more (LE has them), and
you may or may not need the STIMERM subroutine either, depending on what
your application needs to do (LE has a DELAY function, but only for
integer seconds). There are LE callable subroutines to do at least some
of functions that we used to write our own ASM routines to do. Check
out the LE Programmer's Reference manual for your level of z/OS, it has
a lot of interesting information you can use.
All of the above is true.
<ad>
We discuss all the LE callable services in our three day course
"Using LE Services in z/OS", which includes lecture and labs in
any or all (your choice) of Assembler, COBOL, PL/I, and C. This
will give you a solid handle for taking advantage of the available
facilities. See here for more details:
http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm
In addition, the two day course "Enterprise COBOL Update I: Essentials"
covers all the enhancements and changes to the IBM COBOL compiler for
MVS, OS/390, and z/OS since COBOL II through Enterprise COBOL V4R1.
Here you can learn about features such as INITIAL, LOCAL-STORAGE, as
well as compiler options such as THREAD, and much more. See:
http://www.trainersfriend.com/COBOL_Courses/d704descr.htm
In just five days you can get a comprehensive, practical update that
it would take you weeks to get on your own; and you get hands on
experience that is carefully structured to let these features
unfold in a natural progression.
</ad>
It may be possible you that don't need *any* of your in-house ASM
routines any more, so you would not have to migrate them at all.
Maybe. But if you really need the multi-tasking, you'll need to
use some ASM (or PL/I or C) to get that done. If you don't really
need to have multiple tasks, then I agree.
HTH
Peter
P.S. - Feel free to contact me off-list if you want to discuss these
things in more detail.
P.S. - Feel free to contact me off-list if you want to schedule
an offering of "Using LE Services in z/OS" and "Enterprise COBOL
Update I: Essentials".
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
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
