OPSLOG Archive - OPS4626O

[michael.r.dixon]

We're in the planning stage of migrating our production systems from 12.3 to 13.0 over the next few weeks, so I figured now would be a good time to play with the "new and improved" OPSLOG archive method on our test systems. Prior to this, we'd been using the original OPS4403O message triggering a program that eventually started the archive task. 

To date, the new method has been applied on three of our test systems, with message count being the triggering mechanism (as opposed to time). The process works fine when detecting the OPS4403O message; however, I'm a little curious if either I set something up incorrectly or just didn't get it when it comes to the OPS4626O message.

I was under the impression swapping from one OPSLOG to another would generate the OPS4626O message, which would be intercepted by a rule that triggers the archive process. Isn't that why there's an ARCHMSG2 sample rule? What I'm finding, though, is the process automatically runs and, if you do happen to have an enabled OPS4626O, two archives attempt to execute, of which one always fails. 

So, is it fair to say the OPS4626O rule is no longer required under 13.0? Is log swapping automatically handled by ARCHPROC and if so, does it also get involved anywhere else? 

 

Having fun...

-Michael 

[Hennie Hermans]

Hi Michael,

 

the new CA OPS/MVS archive process is not base on the OPS messages anymore... It's now controlled by OPS parameters.  It's the ARCHIVETRIGGER that is important..

This parameter can be a time of day or a number of events in the OPSLOG. 

If you take the amount of BROWSELASTARCH or BROWSEARCHNEEDED and add the ARCHIVETRIGGER amount to it, you will get the messagenumber of the event that triggers the archive procedure to start... 
Or, if the ARCHIVETRIGGER is a time of day, the OPSLOG archive will start at that time of day..

 

See for further information the CA OPS/MVS manual :

OPSLOG Parameters - CA OPS/MVS® Event Management and Automation - 13.5 - CA Technologies Documentation 

 

Best regards,

Hennie Hermans

Principal Support Engineer

[Carlos Filho]

Hi Michael,

 

Some additional information: no message rules are required to intercept either the message OPS4403O nor OPS4626O. With the new OPSLOG archive method, a last archive is automatically triggered when the trigger condition occurs be it the number of messages or the time both expressed in the ARCHIVETRIGGER parameter. So there is no need to a message rule to intercept the message OPS4403O. 

Also, when a switch to the secondary OPSLOG occurs a last archive of the old file is triggered internally, no message rule is required to intercept the message OPS4626O.

The only situation when a message rule is still required is when the message number of the live OPSLOG is approaching the limit of 2 billion:

 

OPS3445O OPSLOG message number approaching "wrap" condition

 

A sample message rule to intercept this message and trigger the switch of the OPSLOG dataset is delivered in the library CCLXRULS member OPS3445O. This rule invokes a REXX program with the same name which is delivered in the library CCLXSAMP. This REXX program OPS3445O performs the automatic switch to the secondary OPSLOG.

 

Regards,

Carlos Mario Filho

Principal Support Engineer

 

 

 

[Anon Anon]

A correction CarlosMario_Filho , the "2 billion" limit you refer to I believe is set in the BROWSEMAX parameter, however unless there is a typo or something has changed, I thought that the BROWSEMAX parameter only went to 2 million (2 950 000), well almost 3 million. This caused us issues on our PROD system that routinely churns out 3M messages a day. Which brings me to my second point or caveat with the new archive system. I see that the OPS3445O message you referenced does say "2 billion" in its description so there my be some confusion or again, maybe a typo?

 

I still use the old message system because of the limitation of the ARCHIVETRIGGER parameter. It can be a message limit OR a TOD but not both. I am currently archiving twice a day (midnight and noon) so the archives have 12 hours a piece. This happens as a scheduled swap from OPSLOG1 to OPSLOG2. Most days there are 2 archives but when our system feels frisky, there are usually 3 or 4 since the message limit is hit. When this message limit is triggered I swap the logs from current to new (OPSLOG1 to 2 or vice versa as the case may be). This then initiates the archive procedure. Now as was mentioned in the Carlos' post the OPS3445O message can be used to swap the log but then I assume you would still need to capture the OP*4626O message to initiate the archive or does the new process automatically detect the swap?

 

When I looked at setting up the new archive method I was moving to 12.3 so 13.0 may have added some functionality but for my purposes, I would still like the ability to trigger an archive off both the message limit AND a TOD (in my case multiple TOD's) so I stuck with the old method. Based on what Carlos has stated, it appears that it is possible to do so but by my estimation, it looks like it would be about the same complexity as the old system so what point is there to move to the new system?

[Carlos Filho]

Hello Travis,

 

The 2 billion messages are not a typo and they don't refer to the BROWSEMAX value. They refer to the maximum message number an event can have in an OPSLOG dataset. This number can be displayed by using the command D MSGNO while browsing an OPSLOG.  When this number reaches its maximum of around 2 billion the OPSLOG dataset becomes unusable and an abend occurs. One of the ways to avoid this situation is to monitor the message OPS3445O that is issued when this number reaches 80% of the maximum and perform a switch to the secondary OPSLOG. See the explanation of the message OPS3445O for details:

OPS3445O OPSLOG message number approaching "wrap" condition

  Modifiable: Yes

  Explanation:

    Each event in the OPSLOG contains a message number.  The number

    must be incremented for each event.  The highest possible message

    number is slightly less than 2 ** 31 or slightly higher then 2

    billion.  The "live" OPSLOG must be switched to a new OPSLOG

    before the "wrap" condition occurs in order to avoid an outage.

    This message is an early warning to switch to a new "live" OPSLOG

    and is issued periodically after it has been detected that the

    message number is approaching a "wrap" condition.

  Action:

    Use an ADDRESS OPSCTL "OPSLOG SETLIVE(logname)" command to switch

    recording to another active OPSLOG, preferably one that has been

    reset and will begin recording at message number 1.  This can be

    done automatically from an AOF rule triggered by this message or

    manually from the appropriate OPSVIEW application.

The sample OPS3445O rule (library CCLXRULS) and REXX program (library CCLXSAMP) I mentioned in my previous update are the recommended procedure to deal with this situation. Please, read the comments section of the rule and REXX for details.

Regarding the ARCHIVETRIGGER parameter you are correct. You can use only a number of messages OR a time of the day on this parameter, not both. 

Lastly, if you use the new archive method you don't need to monitor the message OP*4626O. A last archive of the old OPSLOG is automatically triggered when the switch occurs.

 

Regards,

Carlos Mario Filho

Principal Support Engineer

 

[Anon Anon]

Thanks for the clarification. I did some more digging and found this statement from the 12.2 Manual in the section 

Set the Archive Parameters (12.1 and Earlier)

 

• The ARCHIVETRIGGER parameter determines how many OPSLOG messages accumulate before CA OPS/MVS initiates an archive job. CA OPS/MVS uses the ARCHIVETRIGGER parameter to determine when to issue the OPS4403O message. The default is zero, but you can specify any number of messages up to 1000000000. The number you specify should be about half the size of the number specified for the BROWSEMAX parameter. Setting the ARCHIVETRIGGER value this way gives the archive time to complete before the OPSLOG wraps.

 

This is where my connection of the ARCHIVE process and BROWSEMAX came from. I understand this is from an old version but if we are talking the old archive process this seems relevant. This paragraph would seem to imply that under the old method, the BROWSEMAX was an important part in determining when your log would fill up. Thus, if BROWSEMAX is only 2950000 then you want something around 1-1.5M as your trigger. This statement also seems to contradict itself since ARCHIVETRIGGER's upper max is so high even compared to the old BROWSEMAX value (4950000). I think this old method also assumed that swapping the log was optional or at least that is the impression I got when I first set it up.

[michael.r.dixon]

Hi Travi...

I think as I've been playing with the new process, I saw the archive kick off automatically when the OPS4626O message came out. As I mentioned above, I originally had a rule to capture the OPS4626O message, so when I triggered a swap via 4.13 I was expecting to see the archive kick off. Instead, there were two - my attempt via the rule and the one automatically triggered internally. As Carlos mentioned, it seems there is no longer a need to capture any of the archive triggering messages. Everything is handled by automatically, based on parm settings. The only exception would be the OPS3445O message 

[michael.r.dixon]

Thanks to Hennie and Carlos for their explanation and insight to the new archive process. This does make things easier to implement and handle. A question, though, concerning the OPS3445O message. How close to the magic number does OPS get before the message appears and does it continue to come out at certain intervals?

[Anon Anon]

From the ARCHIVETRIGGER parameter settings in the 12.3 Manual Parameter Reference:

 

• Other possible values:
  Any number between 0 and 99999999
  This value should be smaller than (about half the size of) the value of the BROWSEMAX parameter so that the archive has time to complete before the OPSLOG wraps.
  Any valid time of day in the format of hh:mm.

This again implies the connection between the size of the OPSLOG and BROWSEMAX and when to archive as I mentioned above. It also implies that the answer to michael's question is yes, there is a point in time to start the archive before loss occurs.

 

I think the answer to the second part of michael's question is that if the REXX for OPS3445O runs and performs the SWAP then the archive should be initiated automatically as Carlos stated above. Thus, you should have a fresh new log and the wrap condition shouldn't be present and there is plenty of time to archive the old one. If this is all true then as soon as a SWAP is done, an archive is initiated.

[Carlos Filho]

Hello Travis,

 

Yes, there is a connection between BROWSEMAX and ARCHIVETRIGGER. We still recommend that you set ARCHIVETRIGGER to about half the value of BROWSEMAX. This is because when the number of messages in an OPSLOG dataset reaches BROWSEMAX a wrap condition occurs and oldest messages are discarded. Archiving the events at half way gives opportunity for recovery procedures in case the archival process fails. So, yes, BROWSEMAX is a limit value to be considered when setting ARCHIVETRIGGER.

 

The other limit of 2 billion message number is not related to BROWSEMAX. The message number has its maximum of 2 billion no matter the size of the OPSLOG dataset or the value of the parameter BROWSEMAX. 

 

Regards,
Carlos Mario Filho

Principal Support Engineer

[Carlos Filho]

Hi Michael,

 

The message OPS3445O message appears when the message number reaches 80% of the 2 billion maximum (1717986917).  It occurs only once.

 

Regards,

Carlos Mario Filho

Principal Support Engineer

 

[Anon Anon]

If a WRAP condition occurs at BROWSEMAX and messages are lost (overwritten) shouldn't the message OPS3445O come out at 80% of BROWSEMAX instead of MSGNO? If I recall, once an OPSLOG hits the maximum MSGNO it just fails to work and you are forced to reset it or start using a new OPSLOG correct? Even BROWSEMAX's maximum value is nowhere near 80% of MSGNO so it seems that using MSGNO as an indicator that an archive needs to be done is futile since the log is going to wrap multiple times before hitting the maximum MSGNO.

[Carlos Filho]

Hi Travis.

 

We are discussing here 2 different limits and 2 different actions to be taken on each of them.

1) When MSGNO reaches 2 billion the OPSLOG dataset becomes unusable and a recycle of OPSMAIN will be required to recover from this situation. To avoid this condition CA OPS/MVS issues the message OPS3445O when MSGNO reaches 80% of this limit. We provide a sample rule to perform a OPSLOG switch when this occur. A last archive of the old OPSLOG is triggered automatically as a consequence of the switch.

2) When the number of messages in an OPSLOG dataset reaches the value of BROWSEMAX the oldest messages start to be overwritten by the new ones. In order to keep the OPSLOG information, we recommend that you set ARCHIVETRIGGER to half of the value of BROWSEMAX. To trigger the archive procedure, CA OPS/MVS calculates the difference between the current MSGNO value and the value of the read-only parameter BROWSELASTARCH. If the difference is equal or bigger than ARCHIVETRIGGER the archive process is triggered.

 

Regards,

Carlos Mario Filho

Principal Support Engineer

[Anon Anon]

So what you are saying then is that the archive from OPS3445O is just a byproduct of the swap. If we want to keep our logs we need to make sure we trigger on 1/2 of BROWSEMAX. Of course that could be anytime and any number of times during the day so you could end up with multiple logs covering wildly varying time periods. What I have set up under the old system makes sure that we have a specific time period (00:00 to 12:00 or 12:00 to 00:00) for each of our archives. I usually end up with 2-3 archives per day due to the number of messages we generate and my GDG is set up to keep 180 archives, roughly equating to 80-90 days which seems to be enough for us. On the days I end up with more than 2 archives it is because we exceeded the ARCHIVETRIGGER of 1475000. Currently, this generates message 

OPS4403O that I process with a rule to perform a swap which then initiates the archive. Does reaching the ARCHIVETRIGGER in the new system result in a SWAP or just an archive?

[Carlos Filho]

Hi Travis,

 

Reaching ARCHIVETRIGGER results in just an archive. 

 

Regards,

Carlos Mario Filho

Principal Support Engineer