View previous topic :: View next topic
|
Author |
Message |
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
Hi,
I have a problem in understanding how buffering works for VSAM files.
I created a VSAM ESDS file for logging purpose. Each time, when a CICS program is executed i add 15 records to this file. But, when i execute the transaction multiple times, recent additions are not visible immediately unless until i close the file explicitly?
Can you please let me know the reason for this?
Thanks for your help. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
The answer partially depends upon the usage of LSR pools. With LSR pools being used, CICS won't write filled buffers to the file until it needs additional buffers in the pool (or, as you found out, when the file is closed). If the file is not in an LSR pool the same thing happens but is less obvious because there are fewer buffers associated with a file than an LSR pool (usually -- as always it depends upon the site to some extent).
Why do you feel the need to look at log records so quickly after writing them? |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Robert Sample wrote: |
Why do you feel the need to look at log records so quickly after writing them? |
Maybe to see if his software behaves itself? Creating a log entry after each statement, a kind of debugging? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
If you're writing 15 records consecutively in a loop-fashion, using the MASSINSERT keyword of the WRITE API can save you EXCP's. Note that once you've written all 15, you must issue an UNLOCK API, which causes all 15 to be written in one I-O (internally, by VSAM) instead of 15 individual I-O's.
MASSINSERT is included as part of the WRITE API documentation in the Fine Manual....
Bill |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
If the messages are not critical why would one want to see them immediately?
For real important messages there is the syslog and of course abending the stuff in this case of course without bringing down CICS. |
|
Back to top |
|
|
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
Thanks for your reply.As peter said, i use it for debugging purpose.
I have 15 sub programs which is executed sequentially and i write a record in every program. Each program generates a some random number, which will be used in subsequent program. And i write this value into the file.That's why, i need these records to be visible immediately for browsing once it is written.
Also, i have tried adjusting bufferspace parameter in Cluster definition, Even then i don't see any changes.
Here is my cluster definition.
DEFINE CLUSTER -
(NAME(XXX.YYY.ZZZ) -
VOLUME(SGH487) -
RECORDSIZE(600 9999) -
BUFFERSPACE(24080) -
CYLINDERS(090 10) -
NONINDEXED -
REUSE -
SHAREOPTIONS(2 3) -
SUBALLOCATION) -
DATA -
(NAME(TVS.CS4.TDSSMSG.DATA) -
CONTROLINTERVALSIZE(24080)) |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
The BUFFERSPACE parameter used in the IDCAMS definition of the file is not a good way to impact CICS since CICS pretty much has its own way of handling buffers and won't use the BUFFERSPACE value. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
If the file is only for debugging purposes can you stand the overhead of using a KSDS? If you use ABSTIME timestamp as the key the records would be in sequence and you shouldn't need to concern yourself with CI/CA splits.....
Garry. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
If the RPL OPTCD specifies direct processing (DIR), and NSP is not specified, forced writing of the buffer occurs.
The same happens by using an ENDREQ. |
|
Back to top |
|
|
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
Are these parameters set whenever a file is defined in FCT. I am sorry if my understanding is wrong.
Do we have any CICS command that refreshes or releases buffer records after a transaction is executed.I have tried using commit,syncpoint commands which still doesn't help in my case. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
NageshN wrote: |
Are these parameters set whenever a file is defined in FCT. I am sorry if my understanding is wrong.
Do we have any CICS command that refreshes or releases buffer records after a transaction is executed.I have tried using commit,syncpoint commands which still doesn't help in my case. |
Im talking VSAM IO in assembler here. How such things can be done in CICS programming i dont know. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
I don't recall any way except closing and opening the file to flush the buffers.
I suspect there's a basic design flaw in the process. If you're wanting to generate a random number and use it in the next program, why not write the data to a TS queue that you can then read in the next program? You could still write the file for logging purposes but you wouldn't require the buffers to be flushed since the TSQ data would be available. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
As Robert remembers, I remember the same. The ESDS file needs to be CLOSED and then reOPENED in CICS in order to flush the buffers as well as have its HURBA updated correctly to the VSAM CATALOG.
An alternative for a unique value would be a STCK (Store Clock) instruction.
However, for those planning ahead, the eight-byte STCK value reaches its maximum epoch sometime in September 2042.
Then, you'd need to issue a sixteen-byte STCKE....
Bill |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Bill O'Boyle wrote: |
As Robert remembers, I remember the same. The ESDS file needs to be CLOSED and then reOPENED in CICS in order to flush the buffers as well as have its HURBA updated correctly to the VSAM CATALOG.
An alternative for a unique value would be a STCK (Store Clock) instruction.
However, for those planning ahead, the eight-byte STCK value reaches its maximum epoch sometime in September 2042.
Then, you'd need to issue a sixteen-byte STCKE....
Bill |
With all respect this is nonsense, again im talking Assembler VSAM IO, and you dont have to close/reopen VSAM datasets. Just use the right parameters for the RPL, ACB etc. I have to say this is a lot easier for
KSDS processing compared with ESDS processing. After a ENDREQ for a
ESDS pointers etc are lost, so one has to solve that problem.
Beside that there are a lot of BUFFER routines for VSAM that will do some nice flushing for you. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Quote: |
With all respect this is nonsense, again im talking Assembler VSAM IO, and you dont have to close/reopen VSAM datasets. Just use the right parameters for the RPL, ACB etc. I have to say this is a lot easier for
KSDS processing compared with ESDS processing. After a ENDREQ for a
ESDS pointers etc are lost, so one has to solve that problem.
Beside that there are a lot of BUFFER routines for VSAM that will do some nice flushing for you. |
The original question pertained to ESDS files in CICS and afterall, this is the CICS forum and I was attempting to stay on topic....
Bill |
|
Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009 Posts: 293 Location: U.S.A.
|
|
|
|
Well, yeah, Bill, but STCK is an ASSEMBLER instruction, and everyone knows that nobody in their right mind writes CICS programs in ASSEMBLER.
As for using ABSTIME instead, be cautious. I was once tasked with supporting an application that used ABSTIME to make a record key "unique", but it seems that ABSTIME was not "fine" enough ( only goes down to milliseconds ) - and we ended up with not only duplicate, but even triplicate keys when records were written in very quick succession. I had to tweak the code to compare the ABSTIME portion of each new key to that of the prev key and adjust as necessary to make it unique. BTW, this problem was not discovered during either development or acceptance testing - it only came to light once the app hit production ( of course ). |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Ron,
Actually, the last two bytes of ABSTIME are rounded up to the nearest hundredth, so the last byte is always X'0C' and I can see why this was not finite enough. However, a STCK would be about as unique as you can get, although LE Callable Date routine CEELOCT returns a true millisecond timestamp of "HHMMSSTHM".
I discussed using STCK as another member had suggested that perhaps a KSDS file would be an alternative and define STCK as part of the key or maybe, the entire key itself. But using other than DISPLAY values in a key is frowned upon and I should have raised that as a possible issue.
As far as the fact nobody in their right mind writes CICS/Assembler, I'm left-handed, which make me not in my right mind to begin with.
Bill |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Bill O'Boyle wrote: |
Quote: |
With all respect this is nonsense, again im talking Assembler VSAM IO, and you dont have to close/reopen VSAM datasets. Just use the right parameters for the RPL, ACB etc. I have to say this is a lot easier for
KSDS processing compared with ESDS processing. After a ENDREQ for a
ESDS pointers etc are lost, so one has to solve that problem.
Beside that there are a lot of BUFFER routines for VSAM that will do some nice flushing for you. |
The original question pertained to ESDS files in CICS and afterall, this is the CICS forum and I was attempting to stay on topic....
Bill |
Im so sorry you took this personal, that was not my intention.
What i wanted to say is that for ESDS/KSDS direct writing/flushing
buffers etc. maybe one doesnt have the possibilities in CICS programming.
So you have to revert to the assembler programming, and thats allowed in CICS too. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Peter,
NP, didn't take it personal at all.
Bill |
|
Back to top |
|
|
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
If there exists some routines that flushes and reset ESDS,Can you please let me know. Since, i am not used to assembler. |
|
Back to top |
|
|
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
This looks like Ron has faced the same issue as i have faced. I was able to see as much as 3 records with same timestamp information in my case.
And Using KSDS, i think the overhead is bit more higher. Since, i need to delete -define base cluster, re-edit copybook, changing my COBOL source code, etc... I had to repeat the process to 15 programs.
But Even after that, if i face the same problem i got in ESDS, then it's not worth changing. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Quote: |
But Even after that, if i face the same problem i got in ESDS, then it's not worth changing.
|
ESDS and KSDS work differently.
Since ESDS is sequential, it reduces physical I/O overhead by maintaining new records in buffers until the buffer is full and does the I/O when the buffer has filled.
KSDS can't behave this way as the activity is expected to be random. Records have to be committed to disk when written. If you write records in ascending keys, you don't get the buffering issue that you have with ESDS but you have the same recording sequence as an ESDS.
Garry. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
You could change your SHAREOPTIONS to SHR(4 3).
To ensure data integrity in a shared environment, VSAM provides users of SHAREOPTIONS 4 (cross-region and cross-system) with the following assistance:
Each PUT request immediately writes the appropriate buffer to the VSAM cluster’s DASD space. That is, the buffer in the user’s address space that contains the new or updated data record, and the buffers that contain new or updated index records when the user’s data is key-sequenced.
Each GET request refreshes all the user’s input buffers. The contents of each data and index buffer being used by the user’s program is retrieved from the VSAM cluster’s DASD. |
|
Back to top |
|
|
NageshN
New User
Joined: 17 Dec 2009 Posts: 7 Location: chennai
|
|
|
|
Will that have any impact in performance related issues in CICS? |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
I dont know. You could monitor your program to find how the impact will be (if any). |
|
Back to top |
|
|
|