CICS Command-Level Gurus

[indust...@winwholesale.com]

        I've started doing something similar to the following at the beginning of my programs, lately, and it seems to work just fine.  However, I wanted to run it past you guys to see if it is kosher and/or advisable to continue in this fashion.  Basically, I do this so that a single LINKAGE SECTION communication area is all that is needed and can always be depended upon to be there without storage violations.

        Previously, I allocated a temporary communications area and then XCTL to myself in order to load DFHCOMMAREA as the normal communication area.  I hoped to eliminate the XCTL by using this new technique.

 IF  EIBCALEN NOT > ZERO
     MOVE LENGTH OF DFHCOMMAREA TO EIBCALEN
     EXEC CICS RETRIEVE
               SET      (ADDRESS OF DFHCOMMAREA)
               LENGTH   (EIBCALEN)
               NOHANDLE
     END-EXEC
     IF  EIBRESP = DFHRESP(ENDDATA)
         EXEC CICS GETMAIN
                   SET      (ADDRESS OF DFHCOMMAREA)
                   LENGTH   (EIBCALEN)
                   INITIMG  (LOVALUE)
         END-EXEC
     END-IF
 END-IF.

        Now, note that this is not all of the code involved -- because this code doesn't take into consideration the possibility of receiving (or retrieving) a short communications area.  However, this is enough to give you an idea of what I am doing.  It is also definitely the part which demonstrates the new technique I am employing -- and about which I am concerned about being kosher (even though, as I said, this seems to be working just fine).

Sincerely,

Dave Clark

WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio  45439  USA
(937) 294-5331



*********************************************************************************************
This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission.
*********************************************************************************************

[Frank M. Ramaekers]

Not sure why your doing the RETRIEVE,

 

Basically:

 

1)                   Is there a Common area?  (EIBCALEN>0)

2)                   If so, is it of the size required?  (EIBCALEN=size required or >=)

3)                   Get the address of the COMMAREA:
         EXEC  CICS ADDRESS,                                           *
              COMMAREA(COMMBAR)                                       *
              NOHANDLE.               Get address of CommArea         

4)                   Does it contain an 8-bit identifier at the beginning?

 

 

 

Frank M. Ramaekers Jr.

 

---

_____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at Priva...@ailife.com.

[Frank M. Ramaekers]

(That should read 8-byte identifier, not 8-bit)        J

 

 

Frank M. Ramaekers Jr.

 

---

[Frank M. Ramaekers]

Am I to assume that you will be moving your COMMON AREA to the GETMAIN’ed area?   Not sure why the duplication.

 

If you have ensured that the EIBCALEN is large enough to be handled by your program, you should be good to go.

 

Frank M. Ramaekers Jr.

 

---

From: owner-vs...@Lehigh.EDU [mailto:owner-vs...@Lehigh.EDU] On Behalf Of indust...@winwholesale.com
Sent: Wednesday, August 18, 2010 9:18 AM
To: VSE Discussion List
Subject: CICS Command-Level Gurus

 

        I've started doing something similar to the following at the beginning of my programs, lately, and it seems to work just fine.  However, I wanted to run it past you guys to see if it is kosher and/or advisable to continue in this fashion.  Basically, I do this so that a single LINKAGE SECTION communication area is all that is needed and can always be depended upon to be there without storage violations.

_____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at Priva...@ailife.com.

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 08/18/2010 11:59:31 AM:
> Not sure why your doing the RETRIEVE,

        If there was no communications area passed directly to the program via XCTL or LINK, then the RETRIEVE is in the case START with FROM was used to start the transaction associated with the program.  If there is also no START data, then a default communications area of low values is allocated which the program will then later initialize for its own use.

        Basically, I don't want to mess with one communications area in WORKING-STORAGE and another in LINKAGE and having to move the later to the former.  The logic isn't the question.  The only thing I'm wondering about is programmatically setting the value of EIBCALEN -- because I have traditionally considered all of the EIB fields to be read-only.

[Ken Meyer]

No where do I change the EIBCALEN manually, but I do change the length
of the common area in this manner:

EXEC CICS RETURN
TRANSID(EIBTRNID)
COMMAREA(COMAREA)
LENGTH(COMLEN) ,

Ken Meyer
CSI

On Wed, 18 Aug 2010 13:21:52 -0400
indust...@winwholesale.com wrote:

snip..

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 08/18/2010 01:53:31 PM:
> No where do I change the EIBCALEN manually, but I do change the length
> of the common area in this manner:

> EXEC  CICS RETURN
> TRANSID(EIBTRNID)
> COMMAREA(COMAREA)
> LENGTH(COMLEN)   ,

        Yes, understood.  But does anybody see a problem with directly modifying EIBCALEN in the case where there was no communications area to begin with?  I have programs which also directly modify EIBAID and EIBRESP without problems.  This seemed an easy way to change the logic path which will be taken further down the line in the program.

 MOVE AIDENTER        TO EIBAID.

 MOVE DFHRESP(NORMAL) TO EIBRESP.

[Rusty Swift]

Dave,

 

I have experienced issues, albeit awhile back trying to modify EIB fields (specifically EIBAID). It seems that the local EIB (which is what you would be modifying) can get overlaid by the system EIB in a few instances (like changing addressing modes with an intervening EXEC CICS LINK). I was told by IBM to not rely on any changes made to the local EIB. It is easy and it is tempting, but when it bites you it is tough problem to track down. Just my .02 worth.

 

Rusty

 

From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of indust...@winwholesale.com

Sent: Wednesday, August 18, 2010 1:08 PM
To: VSE Discussion List

[indust...@winwholesale.com]

owner...@Lehigh.EDU wrote on 08/18/2010 04:38:56 PM:
> I have experienced issues, albeit awhile back trying to modify EIB
> fields (specifically EIBAID). It seems that the local EIB (which is
> what you would be modifying) can get overlaid by the system EIB in a
> few instances (like changing addressing modes with an intervening
> EXEC CICS LINK).

        OK, so it is OK to modify what you call the local EIB -- just that such modifications can be lost if CICS refreshes the local EIB based on what you call the system EIB.  Actually, I have observed that behavior before.  It was a few years ago, though.

        On the flip side, though, I have always treated my EIBAID modifications as only good until the next EXEC CICS command, anyway, for just that reason.   ;-)    EIBRESP, of course, is expected to be updated with each EXEC CICS command so that is no problem, either.

        In the case of modifications to EIBCALEN, it would otherwise be a problem to lose that information.  The good thing, though, is that my programs are only written to examine this field during the initialization process anyway.  So, I think I am good to go.  Thanks.