ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Logging and page data sets on z/OS MQ 6.0 subsystems

Post new topic  Reply to topic
 Logging and page data sets on z/OS MQ 6.0 subsystems « View previous topic :: View next topic » 
Author Message
9A5YY
PostPosted: Mon May 22, 2006 2:56 am    Post subject: Logging and page data sets on z/OS MQ 6.0 subsystems Reply with quote

Voyager

Joined: 27 Sep 2005
Posts: 99
Location: Croatia

Hello!
I am migrating the MQSeries for OS/390 2.1 production subsystems
to the Websphere MQ 6.0 for z/OS production subsystems. I must
plan the logging environment and size of page sets and buffer pools
on the new production Websphere MQ subsystems. I found out that
the default allocation values for active logs data sets are
different between these two versions and for the BSDS are the same.
I was comparing the sample members CSQ4BSDS on both versions.
Default allocation values for page data sets are the same for
both versions in the sample member CSQ4PAGE. I don't know what
to do. Do z/OS Websphere MQ 6.0 susbsystems need larger active
log allocations than OS/390 MQSeries susbsystems? In Websphere MQ
book z/OS Concepts and Planning Guide I found suggestions for active log data set
size: 10000 records in test and 180000 records in production. I have
got 45000 records for log data sets in production now. Should I
make it in the same way on production MQ subsystems on z/OS
because at moment the active logs are archived only one time
a day? So, maybe 45000 is too large. Before we had stonger message loads than now.
I concluded that 45000 is good value for peak message loads and certainly good for everage messages
loads. For this conclusion crucial was the sentence in the same book:
'Your logs should be large enough so that it takes at least 30
minutes to fill a single log during peak message load.'
I tried with 180000 records but this is too much. I need 3390-9 DASDs for it.
I couldn't archive active logs and I received the message there is no space on 3390-3 disks.
The RECORDS(82 82) for BSDS I can leave the same I have in current production. The same
is with page data sets RECORDS(20000 10000). I issued the command DISPLAY USAGE PSID(*)
during the peak message load and I found out I have enough space for
messages. Can anyone suggest me what to do with active logs allocations?
If the new version of Websphere MQ needs more space for active logs I must
allocate more than RECORDS(45000) or if it needs space like old version can I put
the same 45000? Did I conclude correct for BSDS and page datasets?


Thanks for help.
Back to top
View user's profile Send private message
dutchman
PostPosted: Wed Jun 07, 2006 4:48 am    Post subject: Reply with quote

Acolyte

Joined: 15 May 2001
Posts: 71
Location: Netherlands

Hi -did you get this resolved?
Back to top
View user's profile Send private message Send e-mail
9A5YY
PostPosted: Fri Jun 09, 2006 12:14 am    Post subject: Reply with quote

Voyager

Joined: 27 Sep 2005
Posts: 99
Location: Croatia

I allocated active logs in the same way I did before on the old production systems. The crucial was sentence: 'Your logs should be large enough so that it takes at least 30 minutes to fill a single log during peak message load.' So, when these new queue managers will come to production I will control the logging. So, if logging will happen too frequent I will change the archive log primary and secundary space allocation parameters to reduce the archive logging frequency. Also in the test environment I can change the active log allocation if frequency of the logging is too high before the new production queue managers become production. I don't expect any problems because I think in both versions logging and log archiving work in the same way.
Back to top
View user's profile Send private message
dutchman
PostPosted: Fri Jun 09, 2006 1:27 am    Post subject: Reply with quote

Acolyte

Joined: 15 May 2001
Posts: 71
Location: Netherlands

Hi - I am intrigued by your statement '... I will control the logging' and '..change the pri/sec alloc..'.

Maybe I've misunderstood what you've said, but If you do that you will probably need to employ some more staff to keep tabs on how the system behaves in a hour-by-hour basis.
That is not what we are there for

You create the logs once to allow for all peaks and troughs - and monitor.

I think the point that the IBM manual is trying to make about the 30 min interval, is that when a log switch takes place, a new active log is being written to. The last thing you want is for the new active log to fill up again whilst it is still archiving the previous one (although it can - and will - happen at a particularly high update period) - and if you're not careful, all your active logs will fill up and the system stop.

So make sure you
1. know what your peak period are and how many updates to expect
2. have enough active logs
3. trap the 'high water mark' warning message stating that you've nearly used up your active logs
4. define the active logs and archive logs on different DASD volume to avoid contention

This is just a quick of-the-cuff summary - more details in the manuals

Regards ... Ruud
Back to top
View user's profile Send private message Send e-mail
9A5YY
PostPosted: Fri Jun 09, 2006 6:33 am    Post subject: Reply with quote

Voyager

Joined: 27 Sep 2005
Posts: 99
Location: Croatia

Sorry, statement with pri/sec was totaly wrong. I made log allocations for new production queue manegers in the same way like queue managers which are still in production. This is the reason why I don't expect problems. I allocated it on many DASDs. I agree with you statement:

You create the logs once to allow for all peaks and troughs - and monitor.

That's the reason why I post my question. I wanted to avoid later problems. If you have more ideas how to predict if these allocatons are enough please let me know how. I can only say that old one are OK. Only difference is, that old production queue managers are on the MQSeries V2.1 and new one will be on Websphere MQ V6.0. Thanks for help!
Back to top
View user's profile Send private message
dutchman
PostPosted: Fri Jun 09, 2006 8:01 am    Post subject: Reply with quote

Acolyte

Joined: 15 May 2001
Posts: 71
Location: Netherlands

Hi - before going into production with V6, just check how often you are currently switching logs. You can do this in 2 ways:

1. print off the bsds and check the archived logs
2. export the master addr space job log and scan (via REXX) for instances of the CSQJ139i message.

I don't believe V6 will have increased the amount of logging - although I'm happy to be corrected - so the figures you'll obtain above should be a good indicator.
Work out a rough average, and if it is less than 30 mins, then consider enlarging the logs.

Cheers ... R
Back to top
View user's profile Send private message Send e-mail
jacky.bright
PostPosted: Wed Aug 16, 2006 1:07 am    Post subject: mq series log problem in os/390 Reply with quote

Newbie

Joined: 15 Aug 2006
Posts: 2

can anybody help me in solving my doubt

Hi,

I faced prob. in production today ... We got error at around 12.20 that MQ 2
of 8 active logs full.

Thereafter, operator had replied the message and the console was asking to
mount tape in 780 tape drive. However operator kept the message un-attended
and left for lunch.

Later application ppl complained tht they are not able to view mq objects.
During tht period even we couldn't cancel TSO users accessing mq objects.

Once logs were taken into tape, all users got terminated. and thereafter
they could view MQ Objects.

Can anyone explain, even though 6 logs were pending why the problem occurred
?

logs appended below...

Jacky....


LOGS :

12.21.57 STC01132 IKJ56221I DATA SET CSQFTA1.B0000002 NOT ALLOCATED, VOLUME
NOT AVAILABLE+
12.21.57 STC01132 IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT
ON SYSTEM, AND CANNOT BE MOUNTED
12.21.57 STC01132 CSQJ008E -MPFT 2 OF 8 ACTIVE LOGS ARE FULL. MPFT NEEDS
ARCHIVE SCRATCH
12.21.57 STC01132 *11 CSQJ021D -MPFT REPLY Y WHEN DEVICE READY OR N TO
CANCEL
12.21.57 STC01132 CSQP018I -MPFT CSQPBCKW CHECKPOINT STARTED FOR ALL
BUFFER POOLS
12.21.57 STC01132 CSQP019I -MPFT CSQP1DWP CHECKPOINT COMPLETED FOR
BUFFER POOL 0, 0 PAGES WRITTEN
12.21.57 STC01132 -MPFT DISPLAY THREAD(*) TYPE(INDOUBT)
12.21.57 STC01132 CSQP019I -MPFT CSQP1DWP CHECKPOINT COMPLETED FOR
BUFFER POOL 1, 0 PAGES WRITTEN
12.21.57 STC01132 CSQP019I -MPFT CSQP1DWP CHECKPOINT COMPLETED FOR
BUFFER POOL 2, 0 PAGES WRITTEN
12.21.57 STC01132 CSQP019I -MPFT CSQP1DWP CHECKPOINT COMPLETED FOR
BUFFER POOL 3, 0 PAGES WRITTEN
12.21.57 STC01132 CSQV401I -MPFT DISPLAY THREAD REPORT FOLLOWS -
12.21.57 STC01132 CSQV420I -MPFT NO INDOUBT THREADS FOUND
12.21.57 STC01132 CSQ9022I -MPFT CSQVDT ' DISPLAY THREAD' NORMAL
COMPLETION
12.21.57 STC01132 CSQP021I -MPFT Page set 0 new media recovery
RBA=0000105F773E, checkpoint RBA=0000105F773E
12.21.57 STC01132 CSQP021I -MPFT Page set 1 new media recovery
RBA=0000105F7DB8, checkpoint RBA=0000105F7DB8
12.21.57 STC01132 CSQP021I -MPFT Page set 2 new media recovery
RBA=00001060973B, checkpoint RBA=00001060973B
12.21.57 STC01132 CSQP021I -MPFT Page set 3 new media recovery
RBA=000012CDBA82, checkpoint RBA=000012CDBA82
13.34.17 STC01132 R 11,Y
13.34.17 STC01132 *IEF233D M 0780,PRIVAT,SL,MPFTMSTR,MPFTMSTR,
CSQFTA1.B0000002,
OR RESPOND TO IEF455D MESSAGE
13.34.17 STC01132 *12 IEF455D MOUNT PRIVAT ON 0780 FOR MPFTMSTR MPFTMSTR OR
REPLY 'NO'
14.07.02 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIAP5 CONNECTION-ID=RTIAP5
THREAD-XREF=000000000000000000000000
14.21.09 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIAP2 CONNECTION-ID=RTIAP2
THREAD-XREF=000000000000000000000000
14.25.01 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIAP3 CONNECTION-ID=RTIAP3
THREAD-XREF=000000000000000000000000
14.37.45 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIAP1 CONNECTION-ID=RTIAP1
THREAD-XREF=000000000000000000000000
14.37.45 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIAP4 CONNECTION-ID=RTIAP4
THREAD-XREF=000000000000000000000000
14.37.45 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=RTIASAJ CONNECTION-ID=RTIASAJ
THREAD-XREF=000000000000000000000000
14.37.45 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.45 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.45 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.45 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.45 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.46 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.46 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.46 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.46 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.46 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.46 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.46 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.46 STC01132 CSQN207I -MPFT COMMAND SERVER UNABLE TO OPEN REPLY TO
QUEUE
14.37.46 STC01132 CSQN203I -MPFT API COMPLETION CODE=2, REASON CODE=2085
14.37.47 STC01132 IEC705I TAPE ON 0780,MPFT01,SL,NOCOMP,MPFTMSTR,MPFTMSTR,
CSQFTA1.B0000002
14.37.52 STC01132 IEC205I SYS00010,MPFTMSTR,MPFTMSTR,FILESEQ=0001,
COMPLETE VOLUME LIST,
DSN=CSQFTA1.B0000002 ,VOLS=MPFT01,TOTALBLOCKS=19
14.37.53 STC01132 IKJ56221I DATA SET CSQFTA2.B0000002 NOT ALLOCATED,
VOLUME NOT AVAILABLE+
14.37.53 STC01132 IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT
ON SYSTEM, AND CANNOT BE MOUNTED
14.37.53 STC01132 CSQJ008E -MPFT 2 OF 8 ACTIVE LOGS ARE FULL. MPFT NEEDS
ARCHIVE SCRATCH
14.37.53 STC01132 *15 CSQJ021D -MPFT REPLY Y WHEN DEVICE READY OR N TO
CANCEL
14.37.58 STC01132 R 15,Y
14.37.59 STC01132 *IEF233D M 0680,PRIVAT,SL,MPFTMSTR,MPFTMSTR,
CSQFTA2.B0000002,
OR RESPOND TO IEF455D MESSAGE
14.37.59 STC01132 *16 IEF455D MOUNT PRIVAT ON 0680 FOR MPFTMSTR MPFTMSTR OR
REPLY 'NO'
14.38.58 STC01132 IEC705I TAPE ON 0680,MPFT02,SL,NOCOMP,MPFTMSTR,MPFTMSTR,
CSQFTA2.B0000002
14.39.03 STC01132 IEC205I SYS00012,MPFTMSTR,MPFTMSTR ,FILESEQ=0001,
COMPLETE VOLUME LIST,
DSN= CSQFTA2.B0000002 ,VOLS=MPFT02,TOTALBLOCKS=19
14.39.43 STC01132 IEC205I SYS00010,MPFTMSTR,MPFTMSTR,FILESEQ=0002,
COMPLETE VOLUME LIST,
DSN=CSQFTA1.A0000002,VOLS=MPFT01,TOTALBLOCKS=12024
14.39.55 STC01132 IEF234E K 0780,MPFT01,PVT,MPFTMSTR,MPFTMSTR
14.39.55 STC01132 CSQJ003I -MPFT FULL ARCHIVE LOG VOLUME
DSNAME=CSQFTA1.A0000002, STARTRBA=000004203000,
ENDRBA=000012CDAFFF,
UNIT=3590, COPY1VOL=MPFT01, VOLSPAN=00, CATLG=NO
14.39.59 STC01132 IEC205I SYS00012,MPFTMSTR,MPFTMSTR,FILESEQ=0002,
COMPLETE VOLUME LIST,
DSN=CSQFTA2.A0000002,VOLS=MPFT02,TOTALBLOCKS=12024
14.40.12 STC01132 IEF234E K 0680,MPFT02,PVT,MPFTMSTR,MPFTMSTR
14.40.12 STC01132 CSQJ003I -MPFT FULL ARCHIVE LOG VOLUME
DSNAME=CSQFTA2.A0000002, STARTRBA=000004203000,
ENDRBA=000012CDAFFF,
UNIT=3590, COPY2VOL=MPFT02, VOLSPAN=00, CATLG=NO
14.40.12 STC01132 CSQJ139I -MPFT LOG OFFLOAD TASK ENDED
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.06 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
14.46.10 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR
USER=TFPUSR CONNECTION-ID=CICSTFP THREAD-XREF=
15.21.38 STC01132 CSQ3201E -MPFT ABNORMAL EOT IN PROGRESS FOR


STMT NO. MESSAGE
2 IEFC001I PROCEDURE MPFTMSTR WAS EXPANDED USING SYSTEM LIBRARY
SYS1.PROCLIB
IEF695I START MPFTMSTR WITH JOBNAME MPFTMSTR IS ASSIGNED TO USER MPFTUSR ,
GROUP PTFM
IEF236I ALLOC. FOR MPFTMSTR MPFTMSTR
IEF237I F331 ALLOCATED TO STEPLIB
IEF237I F327 ALLOCATED TO
IEF237I F331 ALLOCATED TO
IEF237I F329 ALLOCATED TO BSDS1
IEF237I F328 ALLOCATED TO BSDS2
IEF237I F327 ALLOCATED TO CSQINP1
IEF237I F327 ALLOCATED TO CSQINP2
IEF237I F327 ALLOCATED TO
IEF237I F327 ALLOCATED TO
IEF237I F327 ALLOCATED TO
IEF237I F327 ALLOCATED TO
IEF237I F327 ALLOCATED TO
IEF237I JES2 ALLOCATED TO CSQOUT1
IEF237I JES2 ALLOCATED TO CSQOUT2
IEF237I F327 ALLOCATED TO CSQP0000
IEF237I F327 ALLOCATED TO CSQP0001
IEF237I F327 ALLOCATED TO CSQP0002
IEF237I F327 ALLOCATED TO CSQP0003
IKJ56221I DATA SET CSQFTA1.B0000002 NOT ALLOCATED, VOLUME NOT AVAILABLE+
IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND
CANNOT BE MOUNTED
IEC205I SYS00010,MPFTMSTR,MPFTMSTR,FILESEQ=0001, COMPLETE VOLUME LIST,
DSN=CSQFTA1.B0000002,VOLS=MPFT01,TOTALBLOCKS=19
IKJ56221I DATA SET CSQFTA2.B0000002 NOT ALLOCATED, VOLUME NOT AVAILABLE+
IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND
CANNOT BE MOUNTED
IEC205I SYS00012,MPFTMSTR,MPFTMSTR,FILESEQ=0001, COMPLETE VOLUME LIST,
DSN=CSQFTA2.B0000002,VOLS=MPFT02,TOTALBLOCKS=19
IEC205I SYS00010,MPFTMSTR,MPFTMSTR,FILESEQ=0002, COMPLETE VOLUME LIST,
DSN=CSQFTA1.A0000002,VOLS=MPFT01,TOTALBLOCKS=12024
IEF285I CSQFTA1.A0000002 KEPT
IEF285I VOL SER NOS= MPFT01.
IEC205I SYS00012,MPFTMSTR,MPFTMSTR,FILESEQ=0002, COMPLETE VOLUME LIST,
DSN=CSQFTA2.A0000002,VOLS=MPFT02,TOTALBLOCKS=12024
IEF285I CSQFTA2.A0000002 KEPT
IEF285I VOL SER NOS= MPFT02.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Aug 16, 2006 1:15 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

It's considered rude to double post...

I don't think you're going to get further than Mr Butcher comment that your next stop should be IBM. From the look of the log it's trying offload log to tape while there are 6 active logs left & it shouldn't do that. Even if it does, it's shouldn't cause the queue manager to freeze while it's doing it.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » Logging and page data sets on z/OS MQ 6.0 subsystems
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.