Motorola Cell Phone 6806800C47B User Manual

Checkpoint Service

Programmer’s Reference

6806800C47B

September 2007

About this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Models and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.1 Checkpoint Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.2 Checkpoint Node Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.3 Checkpoint Agen t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Compliance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

API Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Service Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 ncsCkptRegisterCkptArrivalCallback() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.2 (*ncsCkptCkptArrivalCallback)(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 8

2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Usage of Non-Collocated Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Checkpoint Service Programmer’s Reference (6806800C47B)

Contents

Checkpoint Service Programmer’s Reference (6806800C47B)

List of Tables

Compliance T a ble - Checkpoint Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ncsCkptRegisterCkptArrivalCallback() Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ncsCkptRegisterCkptArrivalCallback() Return Values . . . . . . . . . . . . . . . . . . . . . . . . . 18

(*ncsCkptCkptArrivalCallback)() Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

SAF-CHK-SVC-v7_5 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Motorola Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Checkpoint Service Programmer’s Reference (6806800C47B)

List of Tables

Checkpoint Service Programmer’s Reference (6806800C47B)

List of Figures

Figure 1-1

Checkpoint Service -Subparts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Checkpoint Service Programmer’s Reference (6806800C47B)

List of Figures

Checkpoint Service Programmer’s Reference (6806800C47B)

About this Manual

Overview of Contents

This manual is divided into the following chapters and appendices.

Chapter 1, Introduction, on page 13

Provides an overview of the Cechpoint service functionilty and provides references to

standard SAF documents.

Chapter 2, API Description, on page 17

Provides information that is required when writing applications that make use of the

Checkpoint service. It also explains non-standard extensions that were added to the

service.

Appendix A, Sample Application, on page 23

Describes the sample application that is available for the Checkpoint service

Provides references to related user documentation and standard specifications.

Abbreviations

This document uses the following abbreviations:

Abbreviation

AIS

Definition

Application Interface Specification

Availability Management Framework

Application Programming Interface

Availability Service

AMF

API

AvSv

CLI

Command Line Interface

CLM

Cluster membershipt Service

Checkpoint Agent

CPA

CPD

Checkpoint Director

CPND

CPSv

DTSv

HPI

Checkpoint Node Director

Checkpoint service

Distributed Tracing Service

Hardware Platform Interface

Layered Environment for Accelerated Portability

Message-Based Checkpoint Service

LEAP

MBCSv

Checkpoint Service Programmer’s Reference (6806800C47B)

About this Manual

Abbreviation

Definition

MDS

MIB

Message Distribution Service

Management Information Base

Netplane Core Services

Service Availability Forum

NCS

SAF

Conventions

The following table describes the conventions used throughout this manual.

Notation

Description

0x00000000

Typical notation for hexadecimal numbers

(digits are 0 through F), for example used for

addresses and offsets

0b0000

bold

Same for binary numbers (digits are 0 and 1)

Used to emphasize a word

Screen

Used for on-screen output and code related

elements or commands in body text

Courier + Bold

Used to characterize user input and to

separate it from system output

Reference

Used for references and for table and figure

descriptions

File > Exit

<text>

Notation for selecting a submenu

Notation for variables and keys

[text]

Notation for software buttons to click on the

screen and parameter description

...

Repeated item for example node 1, node 2,

..., node 12

Omission of information from

example/command that is necessary at the

time being

Ranges, for example: 0..4 means one of the

integers 0,1,2,3, and 4 (used in registers)

Logical OR

No danger encountered. Pay attention to

important information

Checkpoint Service Programmer’s Reference (6806800C47B)

About this Manual

Summary of Changes

This manual has been revised and replaces all prior editions.

Part Number

6806800C47A

6806800C47B

Publication Date

February 2007

Description

First edition

September 2007

Minor text updates for Avantellis Release

3.0.2

Comments and Suggestions

We welcome and appreciate your comments on our documentation. We want to know what you

think about our manuals and how we can make them better.

Mail comments to:

Motorola GmbH

Embedded Communications Computing

Lilienthalstrasse 15

85579 Neubiberg

Germany

[email protected]

In all your correspondence, please list your name, position, and company. Be sure to include

the title, part number, and revision of the manual and tell how you used it.

Checkpoint Service Programmer’s Reference (6806800C47B)

About this Manual

Checkpoint Service Programmer’s Reference (6806800C47B)

Introduction

1.1 Overview

The Checkpoint Service provides a facility for processes to record checkpoint data

incrementally, which can be used to protect an application against failures. When recovering

from fail-over or switch-over situations, or restart situations, the checkpoint data can be

retrieved, and execution can be resumed from the state recorded before the failure.

Checkpoints are cluster-wide entities that are designated by unique names. A copy of the data

stored in a checkpoint is called a checkpoint replica, which is stored in the main memory rather

than on disk for performance reasons. A given checkpoint may have several checkpoint replicas

stored on different nodes in the cluster to protect it against node failures.To avoid accumulation

of unused checkpoints in the system, checkpoints have a retention time. When a checkpoint has

not been opened by any process for the duration of the retention time, the Checkpoint Service

automatically deletes the checkpoint.

The CPSv service supports the following two types of update options:

Asynchronous update option

Synchronous update option

In the case of asynchronous update option, one of the replicas is designated as the active

replica. Data is always read from the active replica and there is no guarantee that all the other

replicas contain identical data. A write call returns after updating the active replica.

In the case of synchronous update options the call invoked to write to the replicas returns only

when all replicas have been updated, i.e. either all replicas are updated or the call fails and no

changes are made to the replicas.

The CPSv supports both collocated and non-collocated checkpoints. In case of checkpoints

opened with collocated and asynchronous update option, it is up to the application to set a

checkpoint to the active state. In all other cases the CPSv itself handles which checkpoint is

currently active.

The CPSv defined by SAF does not support hot-standby. This means that the currently stand-

by component is not notified of any changes made to the checkpoint. When the stand-by

component gets active, it has to iterate through the respective checkpoint sections to get up-to-

date. To overcome this drawback, the CPSv provides additional, non-SAF APIs which help to

notify the stand-by component of changes and thus facilitate the implementation of a hot-stand-

by.

Checkpoint Service Programmer’s Reference (6806800C47B)

Introduction

Models and Concepts

1.2 Models and Concepts

The Checkpoint service comprises three distributed subparts that maintain the cluster-wide

checkpoint database.

Checkpoint Director

Checkpoint Node Director

Checkpoint Agent

Figure 1-1 Checkpoint Service -Subparts

CPD

standby

CPD

active

Payload Blade 2

Payload Blade 1

CPND

CPA

Application

Node SMH 1

Node SMH 2

CPD - Checkpoint Director

Communication path (MDS)

Communication path (MBCSv)

CPND - Checkpoint Node Director

CPA - Checkpoint Agent

SMH - System Manager Host

1.2.1

Checkpoint Director

Checkpoint Director (CPD) runs as a process on a system manager node. CPD maintains the

centralized repository of control information for all checkpoints created in the cluster. The CPD

also maintains the location information of active replicas for all the checkpoints opened in the

cluster. In case of non-collocated checkpoint, the CPD designates a particular node to manage

an active replica for that checkpoint and also decides on the number or replicas to be created

which depends on the policy (See section 8.1.5.1 Usage of Non-Collocated Checkpoints, for

policies). Two instances of CPD are configured, one on each system manager node, in order to

achieve high-availability. The two instances are configured to be part of a service group having

a 2N redundancy model.

1.2.2

Checkpoint Node Director

There is one instance of the Checkpoint Node Director (CPND) on each system manager and

payload nodes. It is modeled as a separate process. CPND maintains the detailed information

of the Checkpoints referred from that node and the corresponding updates and retrievals that

operate on those checkpoints. CPND also handles the requests issued by the CPA instances

on behalf of its client applications on the same node. In case of checkpoints that have been

created with the collocated attribute and the asynchronous update option, the application will

Checkpoint Service Programmer’s Reference (6806800C47B)

Checkpoint Agent

Introduction

choose the CPND that oversees the active replica of a particular checkpoint via the invocation

of the saCkptActiveReplicaSet() API. In all other cases, the CPD will designate the

CPND that oversees the active replica. The CPND that oversees the active replica of a

particular checkpoint will control all the operations on that checkpoint and it is not constrained

to be present on the same node where the application resides. The CPND that manages the

active replica of a particular checkpoint serializes all the requests to that checkpoint from all the

applications present at different nodes in the cluster.

1.2.3

Checkpoint Agent

The Checkpoint Agent (CPA) is a linkable library, which conforms to the SAF APIs described in

the document SAF-AIS-CKPT-B.01.01. The CPA library runs in the context of the application

processes that initialize the CPA library. The SAF APIs are part of this library through which

different checkpoint requests can be issued by the application processes.

1.3 Compliance Report

Checkpoint Service conforms to the Checkpoint specification mentioned in SAF-AIS-CKPT-

B.01.01. The table given below provides the specification conformance report specific to this

release.

Table 1-1 Compliance Table - Checkpoint Service

Section

3.1.1

3.1.2

3.1.3

3.1.4

3.1.5

3.1.6

3.1.7

Description

Supported

Yes

Checkpoints

Sections

Yes

Checkpoint Replica

Checkpoint Data Access

Synchronous Update

Asynchronous Update

Yes

Collocated and Non-Collocated

Checkpoint

Yes

3.1.8

3.1.9

3.2

Active Replica

Yes

Persistence of Checkpoints

Include File and Library Names

Type Definitions

3.3

3.4

Library Life Cycle

3.5

Checkpoint Management

Section Management

Data Access

3.6

3.7

Checkpoint Service Programmer’s Reference (6806800C47B)

Introduction

Related SAF Standard Documents

1.4 Related SAF Standard Documents

The document SAF-AIS-CKPT-B.01.01 is an SAF standard document. It provides the service

definition of the Checkpoint service and can be found at the following location:

http://www.saforum.org/apps/org/workgroup/twg/ais/download.php/1445/aisCkpt.B0101.pdf

The following information can be found in the document:

Service concept definitions and descriptions

Functional behaviors and relationships

A complete set of service data types exposed to the service user

The set of service APIs available to the service user

Checkpoint Service Programmer’s Reference (6806800C47B)

API Description

2.1 Service Extensions

The current release of NCS Checkpoint Service provides one API and a callback function in

addition to the APIs defined in the SAF-AIS Checkpoint Service document SAF-AIS-CKPT-

B.01.01. These APIs are defined as 'stand-alone' APIs so that other SAF-defined APIs are not

disturbed, and compliance to SAF is not compromised. These extensions are defined to provide

the hot-standby support to the Checkpoint Service user applications.

2.1.1

ncsCkptRegisterCkptArrivalCallback()

Prototype

SaAisErrorTncsCkptRegisterCkptArrivalCallback(

SaCkptHandleT ckptHandle,

ncsCkptCkptArrivalCallbackT

ckptArrivalCallback

);

Parameters

The following table describes the possible parameters.

Table 2-1 ncsCkptRegisterCkptArrivalCallback() Parameters

Parameter

Description

ckptHandle - [in]

The handle obtained through the

saCkptInitialize()function,

designating this particular initialization of

the Checkpoint Service.

ckptArrivalCallback - [in]

The function pointer that the CKPT

service shall invoke whenever an opened

checkpoint scoped to ckptHandleis

updated.

Description

This call registers the function callback that will be invoked whenever a opened checkpoint

scoped to ckptHandle is updated. Though it can be invoked any time, the most likely time to

invoke is just after saCkptInitialize()has been invoked. A client will not invoke this call

at all if it does not wish to be notified in real-time about checkpoint updates.

Return Values

Checkpoint Service Programmer’s Reference (6806800C47B)

API Description

(*ncsCkptCkptArrivalCallback)()

The following table lists possible return values of this call.

Table 2-2 ncsCkptRegisterCkptArrivalCallback() Return Values

Return Value

Description

SA_AIS_OK

The function completed successfully

An unexpected problem

SA_AIS_ERR_LIBRARY

SA_AIS_ERR_BAD_HANDLE

SA_AIS_ERR_INVALID_PARAM

SA_AIS_ERR_NO_MEMORY

the handle ckptHandle is invalid

the callback function pointer is wrong

out of memory

2.1.2

(*ncsCkptCkptArrivalCallback)()

Prototype

typedef void(*ncsCkptCkptArrivalCallbackT)(

Const SaCkptCheckpointHandleT checkpointHandle,

SaCkptIOVectorElementT *ioVector,

SaUnit32T

);

numberOfElements

Parameters

The following table lists possible parameters.

Table 2-3 (*ncsCkptCkptArrivalCallback)() Parameters

Parameter

Description

checkpointHandle - [in]

ioVector - [in]

Handle to the checkpoint that is available for reading.

Pointer to a vector that contains elements

ioVector[0],…,ioVector[numberOfElements - 1].

Each element is of the type saCktptIOVectorElementT,

defined in Section 3.3.4.1 of the document SAF-AIS-

CKPT-B.01.01, which contains the following fields:

sectionId - [in] the identifier of the section

available for reading.

dataBuffer - [in] Always set to NULL.

dataSize - [in] size of data available for reading.

dataOffset - [in] offset in the section that marks

the start of the data that is available for reading.

readSize - [in] Always set to 0.

numberOfElements - [in]

the size of the ioVector.

Description

Checkpoint Service Programmer’s Reference (6806800C47B)

Implementation Notes

API Description

If a callback of this form has been registered with the Checkpoint service via

ncsCkptRegisterCkptArrivalCallback(), then it will be invoked whenever new or

updated checkpoint replica data arrives for the checkpoint identified by checkpointHandle. The

checkpoint writer is never called back. Also, applications that have not opened the checkpoint

with the SA_CKPT_CHECKPOINT_READ flag are not called back. This callback is invoked in

the context of a thread issuing saCkptDispatch()call.

The expected behavior for the client application is to take these very same arguments and use

them as-is to invoke saCkptCheckpointRead(), thus fetching the section data that has been

modified in the checkpoint.

For the NCS implementation, this callback function shall report that the data available for

reading is exactly the same set of data that was described and written by the checkpoint writer

that invoked one of saCkptCheckpointWrite(), saCkptSectionOverwrite()or

saCkptSectionCreate(). This means/implies that our NCS implementation shall deliver

checkpoint data in exactly the same units as was written. However, note that this callback is not

invoked when a section is deleted by a writer using the saCkptSectionDelete()API.

Therefore this service extension can only be used if sections created are expected to exist

through the lifetime of the distributed application, i.e. sections that are created by the service

are never deleted.

This function does not conflict or affect the behavior of any other SAF Checkpoint function.

Return Values

n.a.

2.2 Implementation Notes

This section summarizes important information that should be kept in mind when writing

applications that make use of the Checkpoint service.

2.2.1

Usage of Non-Collocated Checkpoints

Checkpoints created without the collocated attribute are called non-collocated checkpoints. The

management of replicas of non-collocated checkpoints and whether they are active or not is the

responsibility of the Checkpoint Service.

For the non-collocated Checkpoints, NCS06A Checkpoint Service will specify the location of the

checkpoint replicas as per the following policy:

If a non-collocated checkpoint is opened for the first time by an application residing on a

payload blade, the replicas will be created on the local payload blade and both the system

manager nodes. In this case, the replica residing on the payload blade is designated as

active replica.

If a non-collocated checkpoint is opened for the first time by an application residing on the

system manager nodes, the replica will be created only on the system manager blade. In

this case, this replica on a system manager node will act as the active replica.

If another application opens the same checkpoint from a payload node, the checkpoint

service will not create the replica on that node.

Checkpoint Service Programmer’s Reference (6806800C47B)

API Description

Time-out Arguments for Checkpoint Service APIs

Creating extra replicas on the system manager node for non-collated checkpoints is an

overhead. The advantage of a non-collocated checkpoint is that replica will be created in two

places, no matter from how many nodes it is opened.

2.2.2

2.2.3

Time-out Arguments for Checkpoint Service APIs

For all synchronous API calls, the application will provide the “timeout” argument. The

application will consider invocation of the particular API failed in case it did not complete the call

by the specified time. CPSv requires that the value passed in the timeout argument is greater

than 100000000 nano seconds (100 milliseconds).

Cancellation of Pending Callbacks

According to the SAF-AIS-CKPT-B.01.01 specification, whenever a checkpoint is closed, all the

pending callbacks corresponding to this checkpoint should be cancelled. In CPSv,

implementation does cancel the pending callbacks related to closed checkpoints. However, the

selection object already raised and related to cancelled pending callbacks, will not be cleared

or reset. Due to this, saCkptDispatchAPI may return without invoking callback routine.

2.2.4

Maximum Number of Replicas Per Node

CPSv applications can create upto 1,000 replicas per node at a given instance. This includes

the replicas created by CPSv for non-collocated checkpoints as per the “replica creation policy.”

In the case of collocated checkpoints, CPSv returns SA_AIS_ERR_NO_RESOURCES if an

application attempts to create a new checkpoint and the current number of replicas on the local

node is already the maximum that CPSv can support per node.

In the case of non-collocated checkpoints, CPSv returns an SA_AIS_ERR_NO_RESOURCES

if the number of checkpoint replicas on the node on which CPSv decides to create a replica is

already the maximum that CPSv can support per node. In all other cases, the checkpoint open

does not return an error but the replicas will not be created on the backup nodes as decided by

the “replica creation policy”.

2.2.5

Handling of SA_AIS_ERR_TRY_AGAIN

If the Checkpoint service API returns SA_AIS_ERR_TRY_AGAIN, the application should

attempt the API call only after a couple of milliseconds. The suggested wait time is 3 seconds

and the number of retries are 12.

Note that the Checkpoint write,overwrite, and read operations may sometime return

SA_AIS_ERR_TRY_AGAIN if called simultaneously. This is to avoid any inconsistencies in the

checkpoint database.

2.3 Configuration

This section describes how the Checkpoint service is preconfigured regarding shared memory

and the maximum write data size.

Checkpoint Service Programmer’s Reference (6806800C47B)

Shared Memory Configuration

API Description

2.3.1

Shared Memory Configuration

NCS3.0 Checkpoint service uses the shared memory for storing the checkpoint replicas.

Checkpoint service will manage the shared memory segments created by it for storing the

checkpoint replicas. The shared memory requirements for storing the checkpoint replica can be

derived from the checkpoint creation attributes supplied at the time of saCkptCheckpointOpen(

) or saCkptCheckpointOpenAsync( ) call using the formula. maxSections *

maxSectionSize

The maximum size of the shared memory segment is limited by the operating system. In most

of the cases, the maximum value is 31MB. This can be found by executing the command: cat

/proc/sys/kernel/shmmax

To increase the shared memory size to the desired value, one can use the following command:

echo 134217728 >/proc/sys/kernel/shmmax

The above example command will set the maximum shared memory segment value to 27MB.

2.3.2

Maximum Data Size Per One write or Overwrite

The maximum data size per one write or over write is 40MB. Applications that try to write more

than 40MB data in one saCkptSectionWrite( )or saCkptSectionOverwrite( ) call

will get the error SA_AIS_ERR_NO_RESOURCES.

2.4 Service Dependencies

The internal interfaces of the Checkpoint service are given below:

Layered Environment for Accelerated Portability (LEAP) - for Shared Memory: Checkpoint

Service uses LEAP for portability. The service uses the memory manager, timers, encode-

decode utility and handle manager services provided by the LEAP.

Message Distribution Service (MDS) - for Messaging: All the interaction between the

different subparts of the Checkpoint service will take place using MDS messaging. The

MDS is also used to register the service up and down events to handle the failure cases.

Distributed Tracing Service (DTSv) - for Logging messages: Checkpoint service uses DTSv

to log debug messages, which are stored in a file and could be used for debugging and to

report informational events.

Availability Service (AvSv) - for High Availability: CPD and CPND are modelled as AMF

components.

Message based Checkpoint Service (MBCSv) - for checkpointing information: CPD uses

the MBCSv to checkpoint the state information with the standby CPD.

Cluster Membership Service (CLM) - for Node names: CPD uses Cluster membership

service to get the node name for a given node ID. Node names are required to implement

Checkpoint service MIBs.

The Checkpoint library libSaCkpt.so depends on functions found in the following library:

libncs_core.so

Checkpoint Service Programmer’s Reference (6806800C47B)

API Description

Management Interface

2.5 Management Interface

SAF-CHK-SVC-MIB is defined by SA forum’s systems management WG. This MIB provides the

manageable objects to access the cluster wide created checkpoint properties, location of the

checkpoint replicas, version supported etc. This MIB also defines the traps to notify the errors

like no more sections, sections available now etc.

NCS Checkpoint Service implements a draft version of SAF-CKPT-SVC-MIB, which aligns with

B.01.01 version of CKPT. Checkpoint Service does not support the Notifications and Traps

defined in SAF-CKPT-SVC-MIB.

The following table describes the MIB objects and traps supported by NCS Checkpoint Service:

Table 2-4 SAF-CHK-SVC-v7_5 MIB

MIB table id \ trap id

Description

safSpecVersion

Supported

safAgentVendor

Supported

safAgentVendorProductRev

safServiceStartEnabled

saCkptCheckpointTable

saCkptNodeReplicaLocTable

saCkptAlarmServiceImpaired

saCkptStateChgNoMoreSections

saCkptStateChgSectionsAvailable

Supported

Supported. Always set to FALSE

Supported

Not Supported

Command Line Interface (CLI) is not supported by Checkpoint Service

Checkpoint Service Programmer’s Reference (6806800C47B)

Sample Application

A.1 Overview

The sample application provided here consists of two application processes that use the

Checkpoint service APIs to ‘write’ to a checkpoint, and ‘read’ the checkpoint data written by the

first application process.

A.2 Run the Checkpoint Service Demo

This sample application assumes that the NCS software is installed and running on the target

system. Refer to the Avantellis 3000 Series Rel. 3.0 User’ s Guide for information on how to

install the NCS software.

Running the demo application:

To run the checkpoint service demo, follow the steps given here:

1. Build the sample program to create the executable file cpsv_demo.out.(Refer to

section - A.4.2 "Make" Commands of the NetPlane Core Services Overview User’s

Guide, Part Number: 6806800C08 for more details)

2. Copy the executable file to the target. (Refer to section - A.4.2 "Make" Commands

of the NetPlane Core Services Overview User’s Guide, Part Number: 6806800C08

for more details)

Ensure the cpsv_demo.outhas executable permission. To give executable

permission, use the following command:

chmod +x cpsv_demo.out

3. Open two terminals, and change to the directory where the executable

cpsv_demo.out is copied.

4. Execute the following command in the first terminal. This application process will act

as “MESSAGE-WRITER”../cpsv_demo.out 1

5. Execute the following command in the second terminal. This application process will

act as “MESSAGE-READER”. ./cpsv_demo.out 0.

The output will be displayed on both the terminals. Refer "Appendix A, Sample

Application Output" of this document.

Checkpoint Service Programmer’s Reference (6806800C47B)

Sample Application

Sample Application Output

A.3 Sample Application Output

MESSAGE_ WRITER

Ckpt Initialising being called ....

PASSED

Ckpt Open being called ....

PASSED

Ckpt Active Replica Set being called ....

PASSED

Ckpt Section Create being called .... PASSED

Ckpt Write being called with data: The Checkpoint Service provides a

facility for processes to record checkpoint data

PASSED

....

Ckpt Synchronize being called ....

PASSED

Ckpt Unlink being called .... PASSED

Ckpt Close being called ....

PASSED

Ckpt Finalize being called .... PASSED

MESSAGE_READER

Ckpt Initialising being called ....

PASSED

Ckpt Open being called ....

PASSED

Ckpt Read being called, data in the read buffer is: The Checkpoint

Service provides a facility for processes to record checkpoint data

.... PASSED

Ckpt Synchronize being called ....

PASSED

Ckpt Close being called ....

PASSED

Ckpt Finalize being called .... PASSED

Checkpoint Service Programmer’s Reference (6806800C47B)