DFHCOMMAREA
Frank Swarbrick
day. First, let me post a code snippet.
LINKAGE SECTION.
01 DFHCOMMAREA PIC X(2125).
PROCEDURE DIVISION.
IF EIBCALEN = ZEROES
GO TO 9300-XCTL-TO-RE10
ELSE
MOVE DFHCOMMAREA TO RE-COMMAREA
IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
PERFORM 1000-SEND-INIT-MAPRE11
ELSE
PERFORM 2000-RECEIVE-MAP.
Basically, this program (CICSRE10) can be entered two ways. If it was
entered via an EXEC CICS RETURN TRANID('RE11') COMMAREA(RE-COMMAREA)
then EIBCALEN would not be zeroes and RECOMM-TRAN-ID would be 'RE11'.
This should trigger the above to do the perform of 2000-RECEIVE-MAP.
The other way it can be entered is a related program (CICSRE10 or
CICSRE12) doing EXEC CICS XCTL PROGRAM('CICSRE11')
COMMAREA(RE-COMMAREA). Again, EIBCALEN would not be zeroes. But in
this case RECOMM-TRAN-ID would be 'RE10' or 'RE12', depending on which
program did the XCTL. We would in this case perform
1000-SEND-INIT-MAPRE11.
But here's the deal. Sometimes the "MOVE DFHCOMMAREA TO RE-COMMAREA"
seems to have no effect. In other words, it's as if that line is not
even there (so RE-COMMAREA remains all low-values, or whatever). We've
used Intertest to trace the program and, even though it seems to 'do'
the move, we can see that nothing is actually moved.
This doesn't happen all of the time, though. In fact, if the user tries
it and it fails, then logs out (to the VTAM menu) and logs back and
tries it again it may work.
The problem does not seem to occur in production. Or at least no user
has ever reported it. One difference between our production CICS and
our test CICS is that production still has the VS COBOL II runtime,
while test has LE/VSE 1.4.1 (VSE/ESA shop...running CICS/VSE 2.3 in both
prod and test).
One thought is this... Even though DFHCOMMAREA is defined as 2125
bytes, EIBCALEN is never near that size. In fact, the RETURN and XCTL
both include the LENGTH parameter and it's much less than 2125. So when
this program does the MOVE it sometimes is accessing storage that is not
available to the program...? The obvious solution it that case is to
change the MOVE to: MOVE DFHCOMMAREA (1:EIBCALEN) TO RE-COMMAREA.
RE-COMMAREA is working storage. It's 2125 bytes, but includes over 1000
bytes of filler. The original programmer did this anticipating future
expansion...
Anyway, we're just wondering if this sounds like it may be the problem.
We have a lot of programs that do this kind of thing, though the others
have nowhere near this much filler. This is the only program we've run
in to this behavior, though, and we've had CICS under LE for three or
four months. Now we're kind of nervous about going in to production
with LE/VSE, though.
Any thoughts?
--
Frank Swarbrick -- now powered by SuSE Linux 7.2
"I'm very seldom naughty" --Willow Rosenberg, 'Buffy the Vampire Slayer'
Richard
> LINKAGE SECTION.
> 01 DFHCOMMAREA PIC X(2125).
>
> PROCEDURE DIVISION.
> IF EIBCALEN = ZEROES
> GO TO 9300-XCTL-TO-RE10
> ELSE
> MOVE DFHCOMMAREA TO RE-COMMAREA
> IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
> PERFORM 1000-SEND-INIT-MAPRE11
> ELSE
> PERFORM 2000-RECEIVE-MAP.
Why is there no 'USING DFHCommArea' on the PROCEDURE DIVISION header ?
docd...@panix.com
The CICS translator supplies it... at least the one on an IBM mainframe
quite often does.
DD
Paul Pigott
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.02071...@posting.google.com...
Unless things have dramatically changed on me, doesn't the CICS translator
insert that small bit of code? (Along with lots of other bits of code?)
Paul
Paul Raulerson
this. The zero test might be TRUE when the length of the comm area is zero.
-Paul
"Richard" <rip...@Azonic.co.nz> wrote in message news:217e491a.02071...@posting.google.com...
David_G_Clark
You've almost got the reason. This is caused because cobol is generating
an assembler Move Characters Long instruction because of the lenght you've
specified. However with the MVCL, there cannot be overlap of storage or the
move never happens and (as far as I know) no error condition is ever raised.
The reason it does not fail consistantly is because CICS would need to
load the programs working storage area next to the passed DFHCOMMAREA which
would be much shorter than the 2125 you've specified and so result in an
overlap of fields. Cobol is going to move 2125 bytes so if the real size is
125, then 2000 bytes of whatever follows gets pulled in - if that happend to
be part of RE-COMMAREA because it happens at that moment in time to follow
the DFHCOMMARA in memory, then nothing is moved and no error condition (at
least at the point of move).
The only way to avoid is to use matching lengths. Even when it does
not fail, you're getting some sort of data moved to the end of RE-Commarea
though program might not referance it so it doesn't cause trobles. Easiest
way is to use referance modification (which I think can be used with cobol II)
MOVE DFHCOMMAREA (1:EIBCALEN) TO RE-COMMAREA
should fix problem if I've remembered the code correctly.
In article <3D34BDA1...@sprynet.com>, inf...@sprynet.com says...
Frank Swarbrick
check for non-zeroes". No difference (well, except the obvious). In
any case, it will never be RETURNed to or XCTL'd to with a commarea of
zero. The only time EIBCALEN is zero is if the transaction is started
by a user on blank CICS screen. In this case we go to RE10, which is
the menu program.
--
Frank Swarbrick
never thought of this being the answer (not knowing assembler very well,
in any case), but it makes absolute sense.
Let me make sure I understand exactly. There are 1576 bytes of
working-storage ahead of the beginning of RE-COMMAREA. So if the
address of EIBCALEN is, say 200, then DFHCOMMAREA could conceivably
start at 200 bytes ahead of that. That would mean that if RE-COMMAREA
is greather than 1776, which it is, then DFHCOMMAREA, being defined as
2125 bytes would overlap with RE-COMMAREA. Does this sound right?
Interesting. I assume that the reason that it sometimes works is
because the DFHCOMMAREA being referred to may or may not be immediately
ahead of program working-storage, correct?
Woah! So it looks like this has nothing to do with COBOL II runtime vs
LE/VSE runtime. Would perhaps the reason it never seems to happen in
production is because the DFHCOMMAREA is never immediately ahead of the
program's working-storage? Or maybe it has happened and no one has
reported it to us. I don't think the transaction is used by too many
people.
Anyway, I think I figured out why no other programs are having this
problem. Our other major programs that have a commarea this large
handle it a bit differently. Something like:
IF EIBCALEN = DD-CA-SIZE
MOVE DFHCOMMAREA TO DD-COMMAREA
ELSE IF EIBCALEN = CU-CA-SIZE
MOVE DFHCOMMAREA TO CU-COMMAREA
etc. etc.
Because the destination is the proper size only that number of bytes is
moved.
Thanks a bunch for your help. We'll fix the offending programs (only 3,
I believe) and go on with our happy programming lives! :-)
Frank
Paul Raulerson
statement somewhere. Believe it or not, sillier things have happened. Your trouble seems to be pretty much related to that kind of
issue. In other words, what would happen if you *did*
get back a comm area with an unexpected length?
Besides which, you should be using the EIBCALEN to determine how much of that comm area to return anyway.
"Frank Swarbrick" <inf...@sprynet.com> wrote in message news:3D360AE1...@sprynet.com...
Frank Swarbrick
that EIBCALEN was zero. It was that EIBCALEN was less than the
declaired size of DFHCOMMAREA.
Anyway, the solution, as already posted, is to use reference
modification "MOVE DFHCOMMAREA (1:EIBCALEN)".
Frank
Volker Bandke
<inf...@sprynet.com> wrote:
>A programmer at my shop came upon a rather strange situation the other
>day. First, let me post a code snippet.
>
>LINKAGE SECTION.
>01 DFHCOMMAREA PIC X(2125).
>
>PROCEDURE DIVISION.
> IF EIBCALEN = ZEROES
> GO TO 9300-XCTL-TO-RE10
> ELSE
> MOVE DFHCOMMAREA TO RE-COMMAREA
> IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
> PERFORM 1000-SEND-INIT-MAPRE11
> ELSE
> PERFORM 2000-RECEIVE-MAP.
>
First things first. MOVE DFHCOMMAREA(1:EIBCALEN) TO RE-COMMAREA is
definitely safe, as opposed to MOVE DFHCOMMAREA TO RE-COMMAREA
>We've
>used Intertest to trace the program and, even though it seems to 'do'
>the move, we can see that nothing is actually moved.
This is exactly what is the case. The size of the areas to be moved
is large enough to call foe MVCL instruction to be used. MVCL,
though, does not allow a destructive MOVE (like MVS would allow).
Therefore the MVCL would stop with cc 3 set, which the cobol compiler
does not react on. This is no bug (neither in CICS nor in Cobol) It
is just the way the cookie crumbles.
Assume EIBCALEN = 100
Move DFHCOMMAREA to RE-COMMAREA might look like this
+---------------+ +------------------------------+
! passed data ! ! RE-COMMAREA at data + 200 !
+---------------+ +------------------------------+
<-- 100 bytes --> <--------- 2000 bytes -------->
<--- EIBCALEN -->
+-------------------------------------+
! DFHCOMMAREA ! same address as passed data
+-------------------------------------+
<--------------- 2000 bytes ---------->
Move DFHCOMMAREA to RE-COMMAREA lead to destructive overlay, as
DFHCOMMAREA and RE-COMMAREA overlap
MOVE DFHCOMMARE(1:EIBCALEN) TO RE-COMMAREA avoids the overlap
Having said that, my question to you? Why use this unnecessary MOVE
in the first place? It is just plain "BAD" (Broken As Designed)
Assume you do the following
PGM A Links to PGM B passing a commarea
PGM B MOVES COMMAREA to WS
PGM B XCTL to PGMC, passsing WS-Commarea
PGMC RETURNS (to PGMA)
Data in Commarea of PGMC never show up in A
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
You will soon meet a stranger who will become your friend.
(Another Wisdom from my fortune cookie jar)
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Frank Swarbrick
Yep, this is exactly what is happening and that is the exact solution.
> Having said that, my question to you? Why use this unnecessary MOVE
> in the first place? It is just plain "BAD" (Broken As Designed)
>
> Assume you do the following
>
> PGM A Links to PGM B passing a commarea
> PGM B MOVES COMMAREA to WS
> PGM B XCTL to PGMC, passsing WS-Commarea
>
> PGMC RETURNS (to PGMA)
>
> Data in Commarea of PGMC never show up in A
I'm not exactly sure what your question is. Number 1, there are no
LINKs involved. The only ways to enter the aforementioned program are
A) from a blank CICS screen, in which case EIBCALEN is zero, B) from
itself view a RETURN TRANSID COMMAREA and C) via XCTL PROGRAM COMMAREA
from another program.
Are you referring to the fact that the COMMAREA is moved to
working-storage at all? If so, all I can say is it's been the shop
standard for 20 years and I can't imagine it being changed now.
Volker Bandke
>> PGM A Links to PGM B passing a commarea
>> PGM B MOVES COMMAREA to WS
>> PGM B XCTL to PGMC, passsing WS-Commarea
>>
>> PGMC RETURNS (to PGMA)
>>
>> Data in Commarea of PGMC never show up in A
>
>I'm not exactly sure what your question is. Number 1, there are no
>LINKs involved.
I know. I was just showing another simple case where copying commarea
to Working storage is harmful
>
>Are you referring to the fact that the COMMAREA is moved to
>working-storage at all? If so, all I can say is it's been the shop
>standard for 20 years and I can't imagine it being changed now.
Yes, that is what I was referring to - Moveing/copying data from
DFHCOMMAREA to WORKING-STORAGE is a "Bad Thing" (TM). But, of
course, changing a 20 year old shop standard, as bad as it may be, is
an "Impossible Thing" (TM) and should not necessarily be tried
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
One of the best automobile insurance policies is a sunday afternoon nap.
YukonMama
>DFHCOMMAREA to WORKING-STORAGE is a "Bad Thing" (TM). But, of
>course, changing a 20 year old shop standard, as bad as it may be, is
>an "Impossible Thing" (TM) and should not necessarily be tried
I think every CICS program in our shop moves DHFCOMMAREA to a place in
WORKING-STORAGE. However a lot are coded like this:
LINKAGE SECTION.
01 DFHCOMMAREA.
05 FILLER PIC X OCCURS 1 TO 3125 DEPENDING ON EIBCALEN.
Which does allow for future expansion. The WS area on the other hand is
defined as an exact length with all the various fields being used.
Hmmmm - only a 20 year old standard?? Seems to be a tad longer than that if my
poor memory serves.
Eileen
Volker Bandke
>>Yes, that is what I was referring to - Moveing/copying data from
>>DFHCOMMAREA to WORKING-STORAGE is a "Bad Thing" (TM). But, of
>>course, changing a 20 year old shop standard, as bad as it may be, is
>>an "Impossible Thing" (TM) and should not necessarily be tried
>
>
>I think every CICS program in our shop moves DHFCOMMAREA to a place in
>WORKING-STORAGE. However a lot are coded like this:
>
>LINKAGE SECTION.
>01 DFHCOMMAREA.
> 05 FILLER PIC X OCCURS 1 TO 3125 DEPENDING ON EIBCALEN.
>
Well, this (similar to reference modification) is safe in the sense
that the destructive overlay problem cannot occur. But, it still is a
"Bad Thing" (TM) :)
I have seen this type of coding at many shops, yes, and it always
boiled down to
"We have been doing it this way forever"
And, when you go back in time, you will find one COBOL programmer who
set up a skeleton for a CICS program many years ago. This programmer
never understood the Linkage section in the first place, and moved
everything "up" into the working-storage because that was way more
familiar. I am not asking you to change the programs - But please,
give a good reason WHY this unnecessary move is done...
And don't even think "This cannot hurt". It can :)
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
When it comes to helping you some people stop at nothing.
Paul Raulerson
that can receive several different COMMAREA definitions.
I have not had anything particularly bad happen.... (yet! :)
"Volker Bandke" <vba...@bsp-gmbh.com> wrote in message news:r64qju0sdbb6mgpe9...@4ax.com...
YukonMama
>Date: 7/23/02 7:46 AM Eastern Daylight Time
>Well, good or bad, sometimes I do move the COMMAREA to WS because I want to
>redefine it, especially when I am using a single program
>that can receive several different COMMAREA definitions.
>I have not had anything particularly bad happen.... (yet! :)
>
Same here. This is the major reason in our shop for moving the DHFCOMMAREA to
WS.
As to Volker's remark about the one programmer creating a skeleton... I have
worked at a shop like that, drove me ever loving crazy as the skeleton was
abysmal but I was forced to use it. Fortunately I didn't discover this shop
standard until I had converted about 150 programs from VOICE to CICS :)
Volker Bandke
<praul...@hot.NOSPAM.rr.com> wrote:
>Well, good or bad, sometimes I do move the COMMAREA to WS because I want to redefine it, especially when I am using a single program
>that can receive several different COMMAREA definitions.
>I have not had anything particularly bad happen.... (yet! :)
01 DFHCOMMAREA.
02 DFHCOMM-X PIC X OCCURRS 1 to 32763 DEPENDING ON EIBCALEN.
01 ANOTHER-CA REDEFINES DFHCOMMAREA.
02 Some-field ...
....
01 STILL-ANOTHER-CA.... REDEFINES DFHCOMMAREA....
.....
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
From an actual insurance claim: Foot broke out and began to run.
Volker Bandke
> Fortunately I didn't discover this shop
>standard until I had converted about 150 programs from VOICE to CICS :)
I would have said the same :)
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
If everything is coming your way, your in the wrong lane.
docd...@panix.com
Volker Bandke <vba...@bsp-gmbh.com> wrote:
>On Tue, 23 Jul 2002 11:46:11 GMT, "Paul Raulerson"
><praul...@hot.NOSPAM.rr.com> wrote:
>
>>Well, good or bad, sometimes I do move the COMMAREA to WS because I want to redefine it, especially when I am using a single program
>>that can receive several different COMMAREA definitions.
>>I have not had anything particularly bad happen.... (yet! :)
>
>
>01 DFHCOMMAREA.
> 02 DFHCOMM-X PIC X OCCURRS 1 to 32763 DEPENDING ON EIBCALEN.
>01 ANOTHER-CA REDEFINES DFHCOMMAREA.
> 02 Some-field ...
> ....
>01 STILL-ANOTHER-CA.... REDEFINES DFHCOMMAREA....
> .....
My memory is, admittedly, porous... but aren't there dialects of COBOL
which did not allow REDEFINES at the 01 level?
DD
Joseph Katnic
>
> My memory is, admittedly, porous... but aren't there dialects of COBOL
> which did not allow REDEFINES at the 01 level?
02 main-dfhcommarea.
04 variable-dfhcommarea occurs 1 to 32763 depending on eibcalen.
02 first-redefine redefines main-dfhcommarea.
04 blah...
02 second-redefine redefines main-dfhcommarea.
04 blah...
docd...@panix.com
Yes, there are ways to get around it, by all means, that was never denied.
DD
Richard Plinston
>
>
> My memory is, admittedly, porous... but aren't there dialects of COBOL
> which did not allow REDEFINES at the 01 level?
There shouldn't be any such restriction in any version that claims to be
Cobol, after all in FDs all 01 level implicitly REDEFINE each other.
You are probably thinking of OCCURs which should never be applied to an
01 (or 77) level.
Hugh Candlin
<docd...@panix.com> wrote in message news:ahlt7n$kv0$1...@panix1.panix.com...
>
> My memory is, admittedly, porous... but aren't there dialects of COBOL
> which did not allow REDEFINES at the 01 level?
Don't they all disallow the use of a REDEFINES of an 01-level field in an FD
?
Alistair Maclean
Hugh Candlin <NoPersonal...@MyDot.Com> writes
--
Alistair Maclean
William M. Klein
differs from compiler to compiler is whether they allow this (superfluous)
clause to be explicit. Some do (as an extension) - most don't.
--
Bill Klein
wmklein <at> ix.netcom.com
"Alistair Maclean" <ld50...@ld50macca.demon.co.uk> wrote in message
news:72S3HDAq...@ld50macca.demon.co.uk...
Hugh Candlin
Alistair Maclean <ld50...@ld50macca.demon.co.uk> wrote in message
news:72S3HDAq...@ld50macca.demon.co.uk...
That doesn't negate my implication. You can use multiple 01-levels in an
FD,
and they are indeed implicit redefines, but I cannot remember ever
being able to use the REDEFINES clause explicitly while defining them.
I could be wrong, as my standard procedure is to define a single FD
01-level,
and READ the file record or segment INTO a Working-Storage copybook
definition,
which contains any necessary REDEFINES (but not at the elementary-level).