PDBI Sample Sessions

Introduction

This chapter contains sample usages of the PDBI. The message exchanges are shown in Table 4-1 to Table 4-16. All scenarios assume that a TCP/IP connection has already been established between the client and the PDBA.

The first column in the tables shows the direction the message is going.

Messages going from the client to the PDBA (requests) are indicated by →.
Messages going from the PDBA to the client (responses) are indicated by ←.

The strings displayed in the Message column are the actual ASCII that would flow over the socket.

Network Entity Creation

This example connects to the PDBA and creates the Network Entities that are needed for all subsequent examples.

Table 4-1 Network Entity Creation Example

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 1, side active))
→	begin_txn(iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_entity (iid 3, id 9195550000, type SP, pctype ansi, pc 123-456-789, ri GT, ntt 222, ccgt no)	The SP Network Entity for SP 9195550000 has been created.
←	rsp (iid 3, rc 0)	The SP Network Entity for SP 9195550000 has been created.
→	ent_entity (iid 4, id 9195555555, type SP, pctype intl, pc 1-234-5, ri SSN, ssn 32, ccgt no)	The SP Network Entity for SP 9195555555 has been created.
←	rsp (iid 4, rc 0)	The SP Network Entity for SP 9195555555 has been created.
→	ent_entity (iid 5, id 9195556666, type SP, pctype natl, pc 12345, ri GT, ccgt no)	The SP Network Entity for SP 9195556666 has been created.
←	rsp (iid 5, rc 0)	The SP Network Entity for SP 9195556666 has been created.
→	end_txn (iid 6)	The write transaction has been ended. The updates have been written to the PDB and will be sent to the EAGLE.
←	rsp (iid 6, rc 0, data (dblevel 1))
→	disconnect (iid 7)	The client is done and has disconnected.
←	rsp (iid 7, rc 0)	The client is done and has disconnected.

Simple Subscription Data Creation

This example shows a normal connection with the creation of a few different kinds of subscriptions.

Table 4-2 Simple Subscription Data Creation Example

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established.
←	rsp (iid 1, rc 0, data (connectId 1, side active))	A PDBI connection has been established.
→	begin_txn (iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_sub (iid 3, imsi 9195551000, dn 9195551212, dn 9195551213, sp 9195550000)	A multi-DN subscription has been created for IMSI 919551000. The DNs associated with the IMSI are 9195551212 and 9195551213. The subscription is on SP 9195550000.
←	rsp (iid 3, rc 0)
→	ent_sub (iid 4, imsi 9195551000, sp 9195551216)	A new DN has been created for an existing IMSI. The DNs associated with the IMSI are 9195551212, 9195551213, and 9195551216. The subscription remains on SP 9195550000.
←	rsp (iid 4, rc 0)
→	ent_sub (iid 5, imsi 9195552000, sp 9195550000)	A IMSI-only subscription has been created. The IMSI is 9195552000. The subscription is on SP 9195550000.
←	rsp (iid 5, rc 0)
→	ent_sub (iid 6, imsi 9195552001, sp 9195550000)	Another IMSI-only subscription has been created. The IMSI is 9195552001. The subscription is on SP 9195550000. This IMSI will be used in a later example.
←	rsp (iid 6, rc 0)
→	ent_sub (iid 7, dn 9195551500, dn 9195551501, dn 9195551502, dn 9195551503, sp 9195555555)	Four separate single DN subscriptions were created. All four DNs are on SP 9195555555.
←	rsp (iid 7, rc 0)
→	end_txn (iid 8)	The write transaction has been ended. The updates have been written to the PDB and will be sent to the EAGLE.
←	rsp (iid 8, rc 0, data (dblevel 1))
→	disconnect (iid 9)	The client is done and has disconnected.
←	rsp (iid 9 rc 0)	The client is done and has disconnected.

Update Subscription Data

This example shows how to:

Add new DNs to an existing IMSI
Move all of the records for a multi-DN IMSI to a new SP
Move anone or more existing stand-alone DN to a new SP, and
Move existing DN to an existing IMSI.

Table 4-3 Update Subscription Data Example

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 3, side active))
→	begin_txn (iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_sub (iid 3, imsi 9195551000, dn 9195551214, dn 9195551215, sp 9195550000)	Two new DNs are being added to the existing IMSI 9195551000. The IMSI already had two DNs (9195551212 and 9195551213) from the previous creation example scenario, giving it a total of four DNs.
←	rsp (iid 3, rc 0)
→	upd_sub (iid 4, imsi 9195551000, sp 9195556666)	This command moves the specified IMSI and its four DNs to the SP 9195556666.
←	rsp (iid 4, rc 0)
→	upd_sub (iid 5, dn 9195551502, dn 9195551503, sp 9195550000)	This command moves the two specified single DN to SP 9195550000.
←	rsp (iid 5, rc 0)
→	upd_sub (iid 6, dn 9195551501, imsi 9195552001)	This command moves the specified standalone DN to be associated with the specified IMSI. The DN will now get its SP from the IMSI.
←	rsp (iid 6, rc 0)
→	end_txn (iid 7)	The write transaction has ended. The updates will be written to the database.
←	rsp (iid 7, rc 0, data (dblevel 2))
→	disconnect (iid 8)	The client is done and has disconnected.
←	rsp (iid 8, rc 0)	The client is done and has disconnected.

This example shows how the upd_sub command works with respect to the V-Flex feature. The following actions are shown in the example:

Create new DN with a VMS

Create new DN on SP/RN
Move an existing DN to a new SP/RN
- This illustrates how update works to replace SP/RN when SP/RN association already existed.
Add a VMS association to an existing DN
- This illustrates how update works to add a 2nd NE association when an association already existed.
Remove an NE association to make room for a 2nd NE association

Note:

All VMSs, GRNs, & SPs in the following example are assumed to be provisioned prior to this example.

Table 4-4 Update Subscription Data Example 2

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 3, side active))
→	begin_txn (iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_sub(iid 3, dn 9195551600, vms 9195553000)	Creating a new standalone DN 9195551600 on VMS 9195553000.
←	rsp (iid 3, rc 0)	Creating a new standalone DN 9195551600 on VMS 9195553000.
→	ent_sub(iid 4, dn 9195551611, sp 9195551100)	One new standalone DN 9195551611 created on SP 9195551100 .
←	rsp (iid 4, rc 0)	One new standalone DN 9195551611 created on SP 9195551100 .
→	upd_sub(iid 5, dn 9195551611, sp 9195556666)	This command moves the specified standalone DN to SP 9195556666.
←	rsp (iid 5, rc 0)
→	upd_sub(iid 6, dn 9195551600, sp 9195556666)	This command adds the second NE association to DN 9195551600. DN 9195551600 is now on VMS 9195553000 (V-Flex) and SP 9195551100 (G-Flex).
←	rsp (iid 6, rc 0)
→	upd_sub(iid 7, dn 9195551600, grn 9196660000)	This command attempts to add a new NE association, but is rejected because it is not clear which NE (there are 2 associated with this DN) to be replaced.
←	rsp (iid 7, rc 1044)
→	upd_sub(iid 8, dn 9195551600, vms none, grn 9196660000)	This command specifies that the GRN should replace VMS 9195553000. DN 9195551600 is now on GRN 9196660000 (NE Query Only option) and SP 9195551100 (G-Flex).
←	rsp (iid 8, rc 0)
→	end_txn (iid 9)	The write transaction has ended. The updates will be written to the database.
←	rsp (iid 9, rc 0, data (dblevel 2))
→	disconnect (iid 10)	The client is done and has disconnected.
←	rsp (iid 10`, rc 0)	The client is done and has disconnected.

This example shows how the upd_sub command works with respect to G-Flex and V-Flex feature interoperability. The following actions are shown in the example:

Create new multi-DN IMSI on SP
Move DN from IMSI and make it a standalone DN on a VMS
Move DN from IMSI and make it a standalone DN on a VMS and the same SP as before
Move multi-DN IMSI to a new SP
Move the standalone DNs that were on the original subscription onto the new SP
Update DN with ASD
Remove ASD from a DN

Note:

All VMSs, GRNs, & SPs in the following example are assumed to be provisioned prior to this example

Table 4-5 Update Subscription Data Example 3

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 3, side active))
→	begin_txn (iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_sub(iid 3, imsi 9195555000, dn 9195551310, dn 9195551311, dn 9195551312, dn 9195551313, dn 9195551314, sp 9195551100)	The IMSI created with 5 DNs. The subscription is on SP 9195551100.
←	rsp (iid 3, rc 0)
→	upd_sub(iid 4, dn 9195551310, vms 9195551400)	The DN 9195551310 has been moved from IMSI 9195555000 to VMS 9195551400. It is no longer associated with SP 9195551100 and will not be routed by G-Flex.
←	rsp (iid 4, rc 0)
→	upd_sub(iid 5, dn 9195551311, vms 9195551400, sp 9195551200)	The DN 9195551311 has been moved from IMSI 9195551000 and made into a standalone DN. The standalone DN 9195551311 is now on VMS 9195551400 and SP 9195551200. G-Flex routing for this DN will not be any different than before this update.
←	rsp (iid 5, rc 0)
→	upd_sub(iid 6, imsi 9195555000, sp 9195556666)	This command moves the specified IMSI at its 3 remaining DNs to the SP 9195556666.
←	rsp (iid 6, rc 0)
→	upd_sub(iid 7, dn 9195551310, sp 9195556666)	The DN was incorrectly moved off of the IMSI and no longer being routed by G-Flex. This update will correct the error in provisioning by putting the DN on the SP that the rest of the original subscription is on. DN 9195551310 was already on VMS and it is now on SP 9195556666. DN is now being routed by G-Flex like the rest of the original subscription.
←	rsp (iid 7, rc 0)
→	upd_sub(iid 8, dn 9195551311, sp 9195556666)	The standalone DN is no longer on this IMSI must be moved in a separate update command to the SP 9195556666. DN 9195551311 was already on the VMS and was just moved from the old SP to the new SP. DN 9195551311 is now on VMS 9195551400 and SP 9195556666.
←	rsp (iid 8, rc 0)
→	upd_sub(iid 80, dn 9195551311, asd 001F247A).	This DN now has additional subscriber data, 001F247A.
←	rsp (iid 80, rc 0)	This DN now has additional subscriber data, 001F247A.
→	upd_sub(iid 81, dn 9195551311, asd none)	This DN now has no additional subscriber data.
←	rsp (iid 81, rc 0)	This DN now has no additional subscriber data.
→	end_txn (iid 9)	The write transaction has ended. The updates will be written to the database.
←	rsp (iid 9, rc 0, data (dblevel 2))
→	disconnect (iid 10)	The client is done and has disconnected.
←	rsp (iid 10, rc 0)	The client is done and has disconnected.

Simple Queries

This example shows a read transaction that queries the data populated in a previous example.

Table 4-6 Simple Queries Example

	Message	Description
→	connect (iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 4, side active))
→	begin_txn (iid 2, type read)	A read transaction has been opened.
←	rsp (iid 2, rc 0)	A read transaction has been opened.
→	rtrv_sub (iid 3, bimsi 9195550000, eimsi 9195559999)	A query for all IMSIs within the range from 9195550000 to 9195559999 was sent. This query does not contain the data parameter; the default value of all is used. This means that the list of DNs associated with IMSI should be present in the response. The response that comes back has just the three IMSIs that were created and updated in the previous examples.
←	rsp (iid 3, rc 0, data (imsis ( (imsi 9195551000, dns(9195551212, 9195551213, 9195551214, 9195551215), sp 9195556666), (imsi 9195552000, sp 9195550000), (imsi 9195552001, dns(9195551501), sp 9195550000) ) ) )
→	rtrv_sub (iid 4, bimsi 9195550000, eimsi 9195559999, data neonly)	This query is almost the same as the one above. This difference is that this one specifies the value neonly for the data parameter. That means that the list of DNs will be omitted from the IMSI information.
←	rsp (iid 4, rc 0, data (imsis ( (imsi 9195551000, sp 9195556666), (imsi 9195552000, sp 9195550000), (imsi 9195552001, sp 9195550000) ) ) )
→	rtrv_sub (iid 5, bimsi 9195550000, eimsi 9195559999, sp 9195550000, data neonly)	This query is almost the same as the two above. In addition to specifying the neonly value, this one also provides an sp parameter to filter for only IMSIs on the specified SP.
←	rsp (iid 5, rc 0, data (imsis ( (imsi 9195552000, sp 9195550000), (imsi 9195552001, sp 9195550000) ) ) )
→	rtrv_sub (iid 6, bdn 9195550000, edn 9195559999)	A query for all DNs within the range from 9195550000 to 9195559999 was sent. The query does not contain the data parameter, so the default value of all is used. This means that the IMSI value for each DN (if not a stand-alone DN) will be present in the response. The response that comes back has just the eight DNs that were created and updated in the previous examples.
←	rsp (iid 6, rc 0, data (dns ( (dn 9195551212, imsi 9195551000, sp 9195556666), (dn 9195551213, imsi 9195551000, sp 9195556666), (dn 9195551214, imsi 9195551000, sp 9195556666), (dn 9195551215, imsi 9195551000, sp 9195556666), (dn 9195551216, imsi 9195551000, sp 9195556666), (dn 9195551500, sp 9195555555), (dn 9195551501, imsi 9195552001, sp 9195550000), (dn 9195551502, sp 9195550000), (dn 9195551503, sp 9195550000) ) ) )
→	rtrv_sub(iid 7, bdn 9195550000, edn 9195559999, sp 9195556666, data neonly)	This query is almost the same as the one above. The differences are that it specifies both the `neonly` value and it provides an sp parameter to filter only for DNs on the specified SP.
←	rsp (iid 7, rc 0, data (dns ( (dn 9195551212, sp 9195556666), (dn 9195551213, sp 9195556666), (dn 9195551214, sp 9195556666), (dn 9195551215, sp 9195556666), (dn 9195551215, sp 9195556666) ) ) )
→	end_txn(iid 8)	The read transaction has been ended.
←	rsp (iid 8, rc 0)	The read transaction has been ended.
→	disconnect(iid 8)	The client is done and has disconnected.
←	rsp (iid 8, rc 0)	The client is done and has disconnected.

Multiple Response Query

This example shows a retrieve command that results in multiple responses coming back. This would happen when there are so many subscriptions matching the query that a single response would be too big to handle. The single response is broken into many smaller responses. The real response size limit is 4KB, but for the purposes of this example it is much smaller.

Table 4-7 Multiple Response Query Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 5, side active))
→	begin_txn(iid 2, type read)	A read transaction has been opened.
←	rsp (iid 2, rc 0)	A read transaction has been opened.
→	rtrv_sub(iid 3, bdn 9195550000, edn 9195559999)	A query for all single DNs within the range from 919550000 to 9195559999 was sent. For this example, the result information will come back in three separate responses.
← ← ←	rsp (iid 3, rc 1016, data (segment 1, dns (dn 9195551212, imsi 9195551000 sp 9195556666), (dn 9195551213, imsi 9195551000, sp 9195556666), (dn 9195551214, imsi 9195551000, sp 9195556666) ) ) ) rsp (iid 3, rc 1016, data (dns (segment 2, dns ((dn 9195551215, imsi 9195551000, sp 9195556666), (dn 9195551500, sp 9195555555), (dn 9195551501, imsi 9195552001, (dn 9195551216, imsi 9195551000, sp 9195556666), sp 9195550000) ) ) ) rsp (iid 3, rc 0, data (dns ((segment 3, dns ((dn 9195551501, imsi 9195552001, sp 9195550000)) (dn 9195551502, sp 9195550000), (dn 9195551503, sp 9195550000) ) ) )
→	end_txn(iid 4)	The read transaction has been ended.
←	rsp (iid 4, rc 0)	The read transaction has been ended.
→	disconnect(iid 5)	The client is done and has disconnected.
←	rsp (iid 5, rc 0)	The client is done and has disconnected.

Abort Transaction

This example shows a write transaction that receives an error on one of its update requests and then aborts the transaction.

Table 4-8 Abort Transaction Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 6, side active))
→	begin_txn(iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	ent_sub(iid 3, dn 9195557000, sp 9195556666)	The DN has been created.
←	rsp (iid 3, rc 0)	The DN has been created.
→	ent_sub(iid 4, dn 9195558000, sp 9195550000)	Another DN has been created.
←	rsp (iid 4, rc 0)	Another DN has been created.
→	ent_sub(iid 5, dn 9195551213, sp 919555555)	The request to create a stand-alone DN 9195551213 failed because the DN already exists.
←	rsp (iid 5, rc 1014, data (dn 9195551213))
→	abort_txn(iid 6)	The client decided to abort the transaction because the previous update failed. This will cause the two DNs created in iid 3 and iid 4 to be rolled back. No data is updated. Note that the client did not have to abort the transaction here. The transaction could have just been ended normally, and the first two DNs would have been created successfully.
←	rsp (iid 6, rc 0)
→	disconnect(iid 7)	The client is done and has disconnected.
←	rsp (iid 7, rc 0)	The client is done and has disconnected.

Update Request In Read Transaction

This example shows a client opening areadtransaction and then trying to send a command to modify data.

Table 4-9 Update Request in Read Transaction Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 7, side active))
→	begin_txn(iid 2, type read)	A read transaction has been opened.
←	rsp (iid 2, rc 0)	A read transaction has been opened.
→	rtrv_sub(iid 3, dn 9195551500)	A query for DN 9195551500 was sent. A response comes back verifying that the DN exists and showing what SP it is on.
←	rsp (iid 3, rc 0, data (dns ( (dn 9195551500, sp 9195555555) ) ) )
→	upd_sub(iid 4, dn 9195551500, sp 9195556666)	The client now tries to move the DN block that was returned in the previous Retrieve request to SP 9195556666. The Update request fails because the client currently has a read transaction open instead of a write transaction.
←	rsp (iid 4, rc 1011)
→	end_txn(iid 5)	The read transaction has been ended.
←	rsp (iid 5, rc 0)	The read transaction has been ended.
→	disconnect(iid 6)	The client is done and has disconnected.
←	rsp (iid 6, rc 0)	The client is done and has disconnected.

Write Transaction In Standby Connection

This example shows the error scenario of a client trying to open awrite transaction in a connection to the Standby PDBA.

Table 4-10 Write Transaction in Standby Connection Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Standby PDBA.
←	rsp (iid 1, rc 0, data (connectId 8, side standby))
→	begin_txn(iid 2, type write)	The client has attempted to open a write transaction on the Standby PDBA. An error is returned. There is no need to end the transaction because it was never successfully started.
←	rsp (iid 2, rc 1006)
→	disconnect(iid 3)	The client is done and has disconnected.
←	rsp (iid 3, rc 0)	The client is done and has disconnected.

Simple Subscription Data Creation with Single Txnmode

This example shows a connection using thetxnmode single connect option with the creation of a few different kinds of subscriptions.

Table 4-11 Simple Subscription Data Creation with Single Txnmode Example

	Message	Description
→	connect(iid 1, version 1.0, txnmode single)	A PDBI connection has been established.
←	rsp (iid 1, rc 0, data (connectId 1, side active))	A PDBI connection has been established.
→	ent_sub(iid 2, imsi 9195551000, dn 9195551212, dn 9195551213, sp 9195550000, timeout 10)	A multi-dn subscription has been created for IMSI 919551000. The DNs associated with the IMSI are 9195551212 and 9195551213. The subscription is on SP 9195550000.
←	rsp (iid 2, rc 0, data (dblevel 1))
→	ent_sub(iid 3, imsi 9195552000, sp 9195550000)	A IMSI only subscription has been created. The IMSI is 9195552000. The subscription is on SP 9195550000.
←	rsp (iid 3, rc 0, data (dblevel 2))
→	ent_sub(iid 4, imsi 9195552001, sp 9195550000)	A IMSI only subscription has been created. The IMSI is 9195552001. The subscription is on SP 9195550000. This is exactly the same type of command as the previous item. It is being done so that the IMSI can be used in a later example.
←	rsp (iid 4, rc 0, data (dblevel 3))
→	ent_sub(iid 5, dn 9195551500, dn 9195551501, dn 9195551502, dn 9195551503, sp 9195555555)	Four separate single DN subscriptions were created. All four DNs are on SP 9195555555.
←	rsp (iid 5, rc 0, data (dblevel 4))
→	disconnect(iid 6)	The client is done and has disconnected.
←	rsp (iid 6, rc 0)	The client is done and has disconnected.

Single IMEI Data

This example shows a normal connection with the creation, update and deletion of a few different kinds of IMEIs.

Table 4-12 Single IMEI Data Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 1, side active))
→	begin_txn(iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	`ent_eir(iid 3, imei 12345678901234, allow yes, gray yes, imsi 9199301234, imsi 9199302266)`	A single IMEI is created on both the allow and gray lists with 2 IMSIs associated with it. SVN is 0.
←	`rsp (iid 3, rc 0)`
→	`upd_eir(iid 4, imei 12345678901234, allow no, block yes)`	The lists associated with the IMEI is now changed to be Block and Gray. The allow list is now turned off.
←	`rsp (iid 4, rc 0)`
→	`dlt_eir(iid 5, imei 12345678901234, imsi 9199302266)`	The specified IMSI is no longer associated with the IMEI.
←	`rsp (iid 5, rc 0)`
→	`dlt_eir(iid 6, imei 12345678901234)`	The IMEI and it’s associated IMSI are removed.
←	`rsp (iid 6, rc 0)`	The IMEI and it’s associated IMSI are removed.
→	`end_txn(iid 7)`	The write transaction has ended. The updates will be written to the database.
←	`rsp (iid 7, rc 0, data (dblevel 1))`
→	`disconnect(iid 8)`	The client is done and has disconnected.
←	rsp (iid 8, rc 0)	The client is done and has disconnected.

IMEI Block Data

This example shows a normal connection with the creation, update and deletion of a few different kinds of IMEI blocks.

Table 4-13 IMEI Block Data Example

	Message	Description
→	connect(iid 1, version 1.0)	A PDBI connection has been established to the Active PDBA.
←	rsp (iid 1, rc 0, data (connectId 1, side active))
→	begin_txn(iid 2, type write)	A write transaction has been opened.
←	rsp (iid 2, rc 0)	A write transaction has been opened.
→	`ent_eir(iid 3, bimei 12345678901000, eimei 12345678901999, block yes)`	An IMEI Block is created with the block list.
←	`rsp (iid 3, rc 0)`	An IMEI Block is created with the block list.
→	`upd_eir(iid 4, bimei 12345678901000, eimei 12345678901999, gray yes)`	The lists associated with the IMEI block are now changed to be block and Gray. Note: the block list was turned on in the previous step
←	`rsp (iid 4, rc 0)`
→	`dlt_eir(iid 5, bimei 12345678901000, eimei 12345678901999)`	The IMEI block is removed.
←	`rsp (iid 5, rc 0)`	The IMEI block is removed.
→	`end_txn(iid 6)`	The write transaction has been ended. The updates have been written to the PDB and will be sent to the EAGLE.
←	`rsp (iid 6, rc 0, data (dblevel 1))`
→	`disconnect(iid 7)`	The client is done and has disconnected.
←	rsp (iid 7, rc 0)	The client is done and has disconnected.

Asynchronous Service Module Card Report

This example shows a connection that has asked to receive the Service Module card Report every 10 seconds with a report complete percent of 90.

Table 4-14 Asynchronous Service Module Card Report Example

	Message	Description
→	connect(version 1.0, dsmrpt yes, dsmrptfreq 10, dsmrptperc 90)	A PDBI connection has been established. The connection has asked for Service Module card Reports every 10 second with a report complete percent of 90.
←	rsp (rc 0, data (connectId 1, side active))
→		No requests sent. 10 seconds later, a report comes out. One Service Module card is not up with the others because it is loading. Another card is excluded because it is corrupt.
←	dsmrpt (rc 0, data (segment 1, level 2912, percent 90, numdsms 20, dsms (dsm (clli atlanta, cardloc 1405, status loading, level 0, loadperc 98), dsm (clli lakemary, cardloc 2104, status corrupt, level 2652))))
→		10 seconds later, another report comes out. Now, the loading card is finished, but the corrupt card is still corrupt.
←	`dsmrpt (rc 0, data (segment 1, level 2917, percent 95, numdsms 20, dsms (dsm (clli lakemary, cardloc 2104, status corrupt, level 2652))))`
→	`disconnect(iid 7)`	The client is done and has disconnected.

Synchronous Service Module Card Report

This example shows a connection that uses the rtrv_dsmrpt request to receive the Service Module card Report.

Table 4-15 Synchronous Service Module Card Report Example

	Message	Description
→	connect(version 1.0)	A normal PDBI connection has been established. At this point, it has not expressed any desire to get a Service Module card Report.
←	rsp (rc 0, data (connectId 1, side active))
→	rtrv_dsmrpt(percent 90)	The connection requests a Service Module card Report with a specific percent complete value of 90. The level 2912 is returned because only two Service Module cards out of the known 20 have not reached that level.
←	rsp (rc 0, data (segment 1, level 2912, percent 90, numdsms 20, dsms (dsm (clli atlanta, cardloc 1405, status coherent, level 2910), dsm (clli lakemary, cardloc 2104, status corrupt, level 2652))))
→	`rtrv_dsmrpt(percent 95)`	The connection requests the Service Module card Report again, this time with a more stringent percent complete value of 95. This time, a smaller level of 2910 is returned in order to satisfy the higher percent value.
←	`rsp (rc 0, data (segment 1, level 2910, percent 95, numdsms 20, dsms (dsm (clli lakemary, cardloc 2104, status corrupt, level 2652))))`
→	`disconnect(iid 7)`	The client is done and has disconnected.

Service Module Card List

This example shows a connection requesting to see the list of Service Module cards. There are only five cards in this example to make the responses smaller.

Table 4-16 Service Module Card List Example

	Message	Description
→	connect(version 1.0)	A normal PDBI connection has been established.
←	rsp (rc 0, data (connectId 1, side active))	A normal PDBI connection has been established.
→	rtrv_dsmlist()	The connection requests to see the Service Module card list. No filter is used, so all Service Module cards should be returned.
←	rsp (rc 0, data (dsms (dsm (clli atlanta, cardloc 1405, status coherent, level 2910), dsm (clli atlanta, cardloc 1407, status coherent, level 2918), dsm (clli lakemary, cardloc 2104, status corrupt, level 2652), dsm (clli lakemary, cardloc 2106, status coherent, level 2920), dsm (clli lakemary, cardloc 2108, status coherent, level 2920))))
→	`rtrv_dsmlist(clli atlanta)`	The connection requests the Service Module card list with a filter for CLLIs with the value of "atlanta".
←	`rsp (rc 0, data (dsms (dsm (clli atlanta, cardloc 1405, status coherent, level 2910), dsm (clli atlanta, cardloc 1407, status coherent, level 2918))))`
→	`rtrv_dsmlist(clli atlanta, cardloc 1407)`	The connection requests the Service Module card list with a filter for CLLIs with the value of "atlanta" and a cardloc of 1407.
←	`rsp (rc 0, data (dsms (dsm (clli atlanta, cardloc 1407, status coherent, level 2918))))`
→	`rtrv_dsmlist(status corrupt)`	The connection requests to see the Service Module card list with a status filter of corrupt. Only corrupt cards should be returned.
←	`rsp (rc 0, data (dsms (dsm (clli lakemary, cardloc 2104, status corrupt, level 2652))))`
→	`rtrv_dsmlist(status loading)`	The connection requests to see the Service Module card list with a status filter of loading. Since there aren't any cards currently loading, NOT_FOUND is returned.
←	`rsp (rc 1013)`
→	`disconnect(iid 7)`	The client is done and has disconnected.