command is nine if the force parameter is not used. If the force parameter is set to yes, the highest
possible number of EAGLE 5 ISS database commands in a single PDBI command is 17.
Multiple Segmented Responses
For some responses, it is possible that all of the data cannot be returned in one response. In this case,
multiple responses for the same request are returned. The first through (N-1)th response have a return
code of PARTIAL_SUCCESS to indicate that there should be more following them. The Nth response
has the return code SUCCESS to indicate that it is the final response. Multiple responses also use the
segment parameter at the beginning of the data section to allow the client to know that no responses
have been missed. The segment parameter value starts at one for the first response and is incremented
by 1 in each subsequent response for that request up to and including the final response that contains
the SUCCESS return code. For consistency, the segment parameter is also present in single message
responses with the value of 1.
Errors Not Returned to Client
Two return codes are not returned to a PDBI client. They are PDBI_INTERRUPTED and
PDBI_UNIMPLEMENTED.
• PDBI_INTERRUPTED is used internally to cancel requests that are in progress if the PDBI client
abnormally disconnects. Since the return value is only used when the connection is broken, obviously
the return code cannot be returned to the client.
• PDBI_UNIMPLEMENTED is used during development of new features and commands to allow
a valid return from commands that have been defined but are not implemented yet. Since the PDBA
currently implements all of the commands described in this specification, the return code cannot
be returned to the client.
Service Module Card Report
The PDBA keeps track of the status of the Service Module cards that it has connectivity to in the
customer's network. Each card reports its information to the PDBA at regular intervals. The PDBA
makes this information available to the PDBI clients in a Service Module card Report. The Service
Module card Report can be requested by the client in several ways. These ways are spelled out in
various commands that actually do the requesting. In all cases, the content and structure of the Service
Module card Report is the same. The intent of the Service Module card Report is to inform the receiver
what percentage of Service Module cards are at a specific database level. This information can be used
by the client to determine when enough Service Module cards have a specific update to consider it
safe for traffic.
The report includes the database level being reported on, the percentage of Service Module cards that
have that level, and the total number of known Service Module cards. Also included is a list of all
Service Module cards whose level did not meet or exceed the mentioned level. For each card in this
list, the report provides the CLLI, card location, database status, and database level. If the database
status is "loading", a percent loaded status is shown.
The client can either receive this report as a response to the rtrv_dsmrpt request, or it may be
periodically received asynchronously if the client specifies the appropriate connect parameters. When
the report is sent as a response to a normal synchronous request, the message begins with the normal
rsp(…) label. However, when the report is sent as an asynchronous message, it begins with dsmrpt(…)
to help identify that this is not a response to any recent request sent.
52
910-6022-001 Revision A, March 2011
PDBI Request/Response MessagesProvisioning Database Interface Manual
To Next Page
Loading...
