|
View previous topic :: View next topic
|
| Author |
Message |
vasif
New User
Joined: 11 Feb 2008
Posts: 35
Location: Chennai
|
|
|
|
To populate repeating fields on CICS screen, I have used WRITEQ QUEUE(QID).... command where QID is built using the EIBTRMID value. When a single user is using that transaction F7(Scroll Backward) and F8(Scroll Fwd) work fine, but when 2 or more users use the same transaction, F8 hit by the 2nd user shows the next screen continuing the 1st users screen data, and sometimes it behaves strangely showing no data at all or satisfying some error conditions causing it to display user error messages.
How to ensure a unique TSQ gets built for each user's invocation of the transaction?
I have even tried QNAME instead of QUEUE |
|
| Back to top |
|
 |
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
This looks more like a re-entrancy problem rather than a problem with TSQ. Are you sure that each user is getting their own copy of working storage? This looks like users are sharing the same working storage.
Garry. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
The QID is not unique.
If you are using the termid as part of the name, then the termid is not unique.
I think that this can occur if users are routed from other CICSs.
You have to look for something unique to the entire network, possibly the netname? |
|
| Back to top |
|
|
TS70363
New User
Joined: 07 Apr 2010
Posts: 94
Location: Bangalore, India
|
|
|
|
| Please check the item number used in the TSQ |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| TS70363 wrote: |
| Please check the item number used in the TSQ |
What the heck does that mean? |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| CICS Guy wrote: |
| The QID is not unique. |
Indeed, this could explain all your symptoms.
| Garry Carroll wrote: |
| This looks like users are sharing the same working storage |
In fact, it looks like they are sharing the same Temporary Storage.
| vasif wrote: |
| I have even tried QNAME instead of QUEUE |
This doesn't help if you keep using the same name for different queues.
| vasif wrote: |
| QID is built using the EIBTRMID value |
Just to be sure, do you use EIBTRMID or EIBTRNID ?
You can use CEDF to easily check the queue name in the WRITEQ TS.
| TS70363 wrote: |
| Please check the item number used in the TSQ |
Only if you have some spare time and nothing else to do! |
|
| Back to top |
|
|
vasif
New User
Joined: 11 Feb 2008
Posts: 35
Location: Chennai
|
|
|
|
| I have checked the queue name and found to be unique by virtue of the EIBTRMID. But how do i ensure that each user gets their own copy of working storage? |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| vasif wrote: |
| I have checked the queue name and found to be unique by virtue of the EIBTRMID. |
Yes, maybe, but how is the uniqueness of the termid guaranteed to be unique?
| Quote: |
| But how do i ensure that each user gets their own copy of working storage? |
Each user already has their own copy of working storage, it's the (TS I assume) queue name that is being shared. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
| Quote: |
Each user already has their own copy of working storage, it's the (TS I assume) queue name that is being shared.
|
We haven't been told the programming language. I'm not too familiar with Cobol, but in Assembler and PL/1 it's easy enough to have the working storage shared. In PL/1, using STATIC definitions in storage declarations results in a single common area of storage being allocated. I expect there's away of causing this in Cobol, too?
Garry. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Garry Carroll wrote: |
| We haven't been told the programming language. I'm not too familiar with Cobol, but in Assembler and PL/1 it's easy enough to have the working storage shared. In PL/1, using STATIC definitions in storage declarations results in a single common area of storage being allocated. |
vasif is a COBOL CICS programmer, so the reasonable assumption is that it is a COBOL CICS problem.
| Quote: |
| I expect there's away of causing this in Cobol, too? |
Now matter what language, if vasif was dealing with 'static' or other shared memory, his skill level would be sufficient enough to know how to "ensure that each user gets their own copy of working storage". |
|
| Back to top |
|
|
vasif
New User
Joined: 11 Feb 2008
Posts: 35
Location: Chennai
|
|
|
|
CICS Guy,
I have displayed the queue name on the screen and observed that they are unique. So i dont think the queues are getting shared.
Garry,
i am using cobol. i also used the RENT compile option this time but in vain.
Plz help!! |
|
| Back to top |
|
|
RAIN YE
New User
Joined: 06 May 2009
Posts: 7
Location: China
|
|
|
|
Hi vasif,
Here I want to know, why you are using TSQ to store the page information, isn't it better to use DFHCOMMAREA? I think it's much more common and it can ensure each transaction has its own storage.
If you insist to use the TSQ(maybe you have your own reason), and you have confirmed that the queue name is unique. As long as you are using terminal ID as part of your queue name, I believe it should be unique. But have you delete the queue whenever your transaction is invoked at the first time, and when it ends normally?
Here is my concern, the queue is created for terminal 1234, somehow, your transaction ended but the queue is not deleted, then the queue 1234 isstill there, maybe it contains the info of second page, then another user happen to be assigned to the same terminal 1234(the previous terminal was released), will the second page be shown to him? Just a guess, maybe you have already handled it properly in your program.
For such kind of issue, usually it's caused by a little bug of coding, as per my limited knowledge. |
|
| Back to top |
|
|
vasif
New User
Joined: 11 Feb 2008
Posts: 35
Location: Chennai
|
|
|
|
Actually i am collecting data from a table(basing on some previous user input) and storing the result set into a TSQ. As the records are more than what can fit on a single page & moreover due to COMMAREA limitation of 32k bytes, i chose TSQ.
I do delete the queue before proceeding with the input provided by the user.
The scrolling functionality is working perfectly well with a single user. The problem is for more than 1 user. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Try using EIBTRMID and something more for your TSQ name.
(something more: a timestamp, userid, cicsid, whatever you can think of).
BTW, Is your program "conversational" or "pseudo-conversational" ? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| & moreover due to COMMAREA limitation of 32k bytes, i chose TSQ. |
Have you considered using Channels & Containersto getaround COMMAREA limit?
Garry. |
|
| Back to top |
|
|
RAIN YE
New User
Joined: 06 May 2009
Posts: 7
Location: China
|
|
|
|
Use channel/container, or getmain to gain more storage and just pass the address through DFHCOMMAREA.
It's weird the TSQ approach has problem when there are more users... |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Be careful passing addresses in DFHCOMMAREA, because if the target program ever becomes "REMOTE" (program is defined to another region in the PPT), your task/program will crash and burn if the target program attempts addressability in the remote-region using the passed-address. 
IBM will tell you in no uncertain terms (and they've been saying this for over 30 years), they highly frown upon and do not encourage passing addresses in DFHCOMMAREA. 
Bill |
|
| Back to top |
|
|
|
|
