| A follow up issue from the customer...
Could you pass the following on to Fiona Smith's group? It is
probably of interest to them.
We had a another occurrence of c961029-4156 on our development server
(gecao2, cicscst1). We had been having a number of U8022 region abends
caused by the application programmers putting a connect statement in their
transaction programs. During a number of the abends, we also had one or
more of the following messages:
ERZ025047I/0161 02/24/97 06:34:59 cicscst1 : An Open File Descriptor
has been left open on the SFS for file
'/.:/cics/sfs/gecao2'/'cicscst1cicsnrectsqfil', index 'cicsnrectsqidx'
It may not have always been the same file. Seventeen days after we had
the first of these, the sfs log volume became full and we had to do a cold
start on sfs to recover. This also goes back to where I had informed Dave
Carew that the instructions that we had been given to prevent the log from
becoming full did not appear to have any affect on the sfs log.
We have two theories about the sfs log full conditions that we have
experienced over the past 5 months. The first is obvious by the above
message. When we started seeing these we shortly thereafter got into a
predicament. The other may or may not have any affect but I thought I
would mention it. We have never experienced any sfs log full on gecao4.
Nor do we notice any periods of it getting any where near full. It always
appears that the number of free pages is very near the total number. On
gecao1, where we have experienced it a few times in the past, it seems to
approach full and then cleans itself up, but never to the number of free
pages that it had before. The BIG difference between the two systems is
that on gecao4, the log was created at a very large size. On gecao1, we
have a number of smaller regions that have been added to it as the need for
more arose. Could the sfs logging facility have a problem handling a
number of smaller regions that have been added vs. one larger region? To
illustrate my point, I have attached below the output from a tkadmin
command:
gecao1> tkadmin query pvol log_Sgecao1_P
Information about physical volume log_Sgecao1_P
All sizes and offsets are in pages. Page Size is: 4 Kbytes
Mapped to logical volume log_Sgecao1
chunkSize: 64
numRegions: 5
region 0: disk: /dev/rvol/rootdg/log_Sgecao1 offset: 0 size: 32704
region 1: disk: /dev/rvol/rootdg/log_Sgecao1-2 offset: 0 size: 16320
region 2: disk: /dev/rvol/rootdg/log_Sgecao1-3 offset: 0 size: 32704
region 3: disk: /dev/rvol/rootdg/log_Sgecao1-4 offset: 0 size: 65472
region 4: disk: /dev/rvol/rootdg/log_Sgecao1-5 offset: 0 size: 65472
total size: 212672
gecao4> tkadmin query pvol log_Sgecao4_P
Information about physical volume log_Sgecao4_P
All sizes and offsets are in pages. Page Size is: 4 Kbytes
Mapped to logical volume log_Sgecao4
chunkSize: 64
numRegions: 1
region 0: disk: /dev/rvol/rootdg/log_Sgecao4 offset: 0 size: 131008
total size: 131008
We are proposing that as a regularly scheduled task (we have mentioned
five to six months) that we will cold start the sfs to clear up the log
volume. We have also decided that during the next cold start on gecao1,
that we attempt to create the log as one large region like we have on
gecao4.
Do any of the Digital CICS people have any comment on what I have stated
here?
Thank you,
Brian Schroeder
email: [email protected]
Brian Schroeder
8*235-7405
|