Testnap
--------------------------------------------------------------------------------
Dependencies
Syntax
Parameters
Testnap Commands
Error Handling
Error Example 1
Error Example 2
Example
--------------------------------------------------------------------------------
The testnap utility allows a developer to manually interact with the Infranet® server by establishing a PCM connection with the Connection Manager (CM), and then executing PCM operations using that connection. Using testnap, a developer can:
create input flists
save input and output flists
send opcodes
view return (output) flists
create, view, modify, and delete objects and their fields
open, commit, and abort transactions
For examples and information on using testnap, see Testing Your Applications and Custom Modules.
Opcode Workbench, part of the Developer Center offers similar functionality in a GUI-based application. See Testing Your Applications and Custom Modules and the Opcode Workbench help system for detailed information.
Dependencies
The testnap utility requires a pin.conf configuration file to connect to your Infranet system. You can either use the CM's pin.conf file, or run testnap from a directory that contains a suitable pin.conf file, such as Infranet_home/sys/test.
The testnap utility relies on POID logins and types to identify the specific account or storable class to modify. A POID database number is required as a placeholder only.
The necessary pin.conf information is:
- nap cm_name hostname # Name of the system where the cm is running.- nap userid 0.0.0.1 /service/pcm_client 1 # Database number, 0.0.0.1 by default.- nap login_type 1 # Type 1 means login with password.- nap login_name root.0.0.0.n # Username testnap uses to log in to Infranet.- nap login_pw password # Password is "password" by default. Differs from one Infranet installation to another. - nap cm_ptr ip hostname 11960 # CM pointer: protocol hostname port. Allows multiple CM's to be specified in a pin.conf file. The application will try them consecutively until one works or there are no more "cm_ptr" entries.
The correct path to the shared libraries must also be configured. The library path is configured by default to point to the standard libraries in infranet_home_dir/lib. If the libraries are not in infranet_home_dir/lib, then you must set the library path environment appropriately.
Syntax
% testnapnap (pid)> command args
Parameters
The testnap utility allocates numerous internal buffers, which are used to store object or flist fields. Buffers are referenced by integers of the user's choice. Every time a new buffer is referenced, testnap allocates that new buffer.
If you do not specify a buffer number for a command that expects one, you will be prompted for a buffer number.
The meta keyword causes testnap to display the size of external buffer fields. By default, the contents of external buffer fields are displayed.
Testnap Commands
r ((token file buf
Read an flist or object from a file and put it in a testnap buffer. The ((token operator causes testnap to read from stdin until the token string is read.
r+ ((token file buf
Read and append flist to existing buf. The ((token operator causes testnap to read from stdin until the token string is read.
w buf file
Write contents of testnap buffer to a file.
w+ buf file
Append contents of a testnap buffer to the same file.
l
List the testnap buffers that are currently in use.
d buf
Display a testnap buffer.
! cmds args
Run a shell command (for UNIX systems only).
s buf
Save an flist or object from the input buffer to a testnap buffer.
( file
Execute cmd script.
p (property> (value>
Display or set properties.
q
Quit this program.
h, help,?
Print usage help message.
create buf | poid
Create an object. Run PCM_OP_CREATE_OBJ and print the return flist to stdout. The poid keyword causes the poid id of the object that is created to be the poid id specified in the input flist.
delete buf | - (db> (type> (id>
Delete an object. Run PCM_OP_DELETE_OBJ and print the return flist to stdout. The poid of the object to be deleted can be specified on the command line.
robj buf | - (db> (type> (id> meta
Read an object. Run PCM_OP_READ_OBJ using either the poid in the flist in buf, or the poid specified on the command line. Prints the return flist (the contents of the object) to stdout.
rflds buf meta
Read fields. Run PCM_OP_READ_FLDS using the flist in buf, and print the return flist to stdout. Each field (or row) in the field list must be in a valid flist format. The values for the last field are arbitrary, but must be valid for their type. For example, you have to include "" for STR fields and (some number) for a TSTAMP field. If either of these fields are blank, an error is returned.
wflds buf
Write fields. Run PCM_OP_WRITE_FLDS and print the return flist to stdout.
dflds buf
Delete fields. Run PCM_OP_DELETE_FLDS and print the return flist to stdout.
search buf meta count
Search. Run PCM_OP_SEARCH and print the return flist to stdout. The count operator sets the PCM_OPFLG_COUNT_ONLY flag, which causes search to return only the number of matches found by the search. The count is returned as the ELEM_ID of the RESULTS array on the output flist.
ssrch buf meta
Step-search. Run PCM_OP_STEP_SEARCH and print the return flist to stdout.
snext buf meta
Step-search next. Run PCM_OP_STEP_NEXT to get the next object in a step search, and print the return flist to stdout.
send buf
End step-search. Run PCM_OP_STEP_END and print the return flist to stdout.
gdd buf | - (db> (type> (id>
Get data dictionary. Run PCM_OP_GET_DD and print the return flist to stdout. The poid can be specified on the command line.
sdd ( flags> buf
Set data dictionary. Run PCM_OP_SET_DD and print the return flist to stdout.
sort buf sort_buf descending_flag
Read contents of buf, sort it non-recursively using the template in sort_buf, and print the sorted flist to stdout. Available on UNIX only. The descending flag is optional, with 0 (the default) indicating ascending order, and any non-zero integer indicating descending order.
Sorting is not implemented for the following:
POID
BINSTRS
BUFFERs
ERRBUFS
The number of ARRAY elements in the sort specification is ignored. Use 0. Sort specifications just need valid numbers. The numbers are not necessarily valid or desired values for the current sort; they are basically required place-holders.
rsort buf sort_buf descending_flag
Recursive sort. Read contents of buf, sort it recursively using the template in sort_buf, and print the sorted flist to stdout. Available on UNIX only. The descending flag is optional, with 0 (the default) indicating ascending order, and any non-zero integer indicating descending order.
open ro|rw|lock buf | - (db> (type> (id>
Open transaction. Run PCM_OP_TRANS_OPEN and print the return flist to stdout.
commit
Commit the current transaction. Run PCM_OP_TRANS_COMMIT and print the return flist to stdout.
abort
Cancel the current transaction. Run PCM_OP_TRANS_ABORT and print the return flist to stdout.
inc buf
Increment one or more fields of an object. Run PCM_OP_INC_FLDS and print the return flist to stdout.
noop buf
Run non-operational opcode. Run PCM_OP_TEST_LOOPBACK on that database and print the return flist to stdout.
pass buf
Run a pass_thru op to server. Run PCM_OP_PASS_THRU, an extension op that just sends an flist to a DM that supports it.
xop op flag buf
Run opcode op with flags set to flag, the contents of buf as the input flist, and print the sorted flist to stdout.
id
Print user and session ID.
echo string
Echo a string.
Error Handling
If an error occurs, the contents of the error buffer (ebuf) which corresponds to the error are written to stderr.
Error Example 1
# Delete attempt with the - argument missing:pin@demo5-668> testnap===> database 0.0.0.1 from pin.conf "userid"nap(27459)> delete 0.0.0.1 /account 1ERROR: bad number "0.0.0.1"no object to use for delete
Error Example 2
# Attempt to read a non-existent object:nap(10191)> robj - 0.0.0.1 /account 11988PCM_OP_READ_OBJ failed: err 3:PIN_ERR_NOT_FOUND, field 0/16:PIN_FLD_POID, loc 4:PIN_ERRLOC_DM, errclass 4:PIN_ERRCLASS_APPLICATION, rec_id 0, resvd 30001nap(10191)>
For more information on the error buffer, see Understanding API Error Handling and Logging.
Example
For an extensive set of examples refer to the Examples section of Testing Your Applications and Custom Modules.
Friday, June 24, 2005
Thursday, June 23, 2005
Tuesday, June 21, 2005
A 2 ZEE :- Test Nap erros and debugging
--------------------------------------------------------------------------------
About this document
About adding new client applications
Ways to add custom applications
Using existing system opcodes
Using custom opcodes
Using a custom Data Manager (DM)
Handling transactions
Configuring your custom application
Creating a client application in C
Compiling and linking your programs
Guidelines for developing applications in C on Windows
Guidelines for developing applications in C on UNIX platforms
Using the sample applications
Sample applications
Policy FM source files
Adding Branded Service Management to your application
The brand as an independent virtual workspace
Data scoping
Pointing a base level object to a brand account
Defining a brand account
Providing access to brands
Branding access permissions
Providing access to pricing information
Billing groups
Providing billing group access with an Access Control List (ACL)
Managing custom applications
Creating brands programmatically
Writing brand-aware applications
Displaying a list of user authorized brands
Setting the current connection scope
About adding multidatabase support to your applications
About working with multiple databases
Creating accounts
Maintaining transactional integrity
Working with replicated objects
Searching for accounts across databases
Searching for a single account
Searching for multiple accounts (global search)
Finding out how many databases you have with testnap
Bill numbering
--------------------------------------------------------------------------------
About this document
This section describes how to add new client applications and how these applications function within the Infranet® system. It includes general information about writing client applications in all supported languages as well as specific information about writing applications in C. The section also contains links to sample applications and their corresponding Makefiles.
To create a custom application that communicates with Infranet, you need to understand the following Infranet components:
Storable classes and storable objects
See Understanding Infranet Flists and Storable Classes.
Portal Object ID (POID) management routines
See Portal object ID (POID).
Flists and flist routines
See About flists.
PCM opcodes and the PIN library routines
See Understanding the PCM API and the PIN Library.
Error-handling routines
See Understanding API Error Handling and Logging.
About adding new client applications
Client applications can be virtually any type of program, including GUI-based tools, Web-based tools, network-enabled applications, batch jobs, cron jobs, and so on. You can write custom application programs to create, manipulate, delete, and display custom storable objects, which in turn implement a business policy.
The base Infranet system comes with a set of client applications that manipulate storable objects within the database. You may, however, require custom applications. The most common custom application captures external events of some type. These events are then submitted to Infranet, details of the event stored, and the event charges assessed if necessary.
For example, a Web hosting application needs to track the number of bytes downloaded and disk space used. This requires an application to analyze disk-space usage and send it to the Rating EM at the end of each month. This also requires a new event type and new policy code that picks the rate category or quantity for the event.
Web servers don't provide an API to display the web usage automatically, so you might want to write an application that looks at the Web log files and generates events in Infranet. Because of the potential number of records in the Web logs, you can aggregate the data externally, and then send the summary to Infranet as events daily or monthly.
Infranet includes a set of client libraries that make it easier to create custom applications. Existing Infranet applications use these client libraries. These libraries are supported on Solaris, AIX, HP-UX, Windows 95, Windows 98, Windows 2000, and Windows NT. For more information about the libraries, see About the Infranet client access libraries.
For guidelines on writing Windows applications, see Guidelines for developing applications in C on Windows.
Ways to add custom applications
You can use the following options when you add custom applications to Infranet:
Using existing system opcodes.
Using custom opcodes.
Using a custom Data Manager (DM).
Using existing system opcodes
You use the base opcodes to create, read, write, delete, and search storable objects. The base opcodes also provide programmatic access to transaction commands. More complex opcodes are implemented by the Facilities Modules (FMs). You use the policy opcodes to implement business decisions. These higher-level opcodes are translated by the FMs to base opcodes and sent to Data Managers (DMs) for processing.
For more information on the different categories of opcodes and how they are used, see Understanding the PCM API and the PIN Library.
In a client application, you use opcodes to record events such as purchasing a product, changing a credit limit, creating an account or service, changing customer information, charging for use of a resource, verifying a password, and looking up names and addresses.
In your application, you can call any of the Infranet opcodes without changing the Infranet system. You need to determine when to use a particular system opcode, what constitutes an event, and then call the appropriate opcode in your application.
Your application must include the header files corresponding to the opcodes you use. All FM opcodes include the header file for base opcodes, so you don't need to include it unless your application uses only base opcodes.
For a list of opcodes and their corresponding header files, see Header files.
Using custom opcodes
If the system opcodes don't provide the required functionality, you can create custom opcodes. However, you must implement your new opcodes in a custom FM and configure the custom FM with each Connection Manager (CM).
For the application to communicate with the custom FM, the application and the FM have to agree on the opcodes to pass and the contents of their input and output flists, error buffers, and flags. The custom FM translates the new opcodes into base opcodes. Then, it can send the opcodes directly to a DM, or it can call other opcodes implemented by the standard FMs.
For information on how to create a custom FM and link it to a CM, see Writing a Custom Facilities Module.
You call the custom opcodes in the same way with the same API by using PCM_OP() as the system opcode. Therefore, you must supply all the parameters, just as in the case of a system opcode.
Create a header file in which you define your custom opcodes. Include the header file in both the application and the custom FM source files. Compile the application and the custom FM with the new header file.
For examples of including opcodes in the header file, see pcm_ops.h in the Infranet_home/include directory.
Tip Defining your custom opcodes in a separate .h file helps you avoid updating FM header files when you upgrade to a new release of Infranet.
Using a custom Data Manager (DM)
Your application can communicate with a custom DM if the custom DM and the application agree on the semantics of the input and return flists.
You attach fields to the input flist that have meaning to the custom DM. These new fields act as opcodes to the custom DM. The return flist is the mirror image of the input flist in the sense that the application and custom storage manager agree on the meaning of the field-value pairs returned by the storage manager. The storage manager is responsible for setting error buffer values.
For information on creating and implementing a custom DM, see Writing a Custom Data Manager.
You create new fields with the PIN_MAKE_FLD macro. For information on the PIN_MAKE_FLD macro, see pcm.h in the Infranet_home/include directory for field value ranges and examples of PIN_MAKE_FLD.
Tip To avoid updating the Infranet.h files every time you upgrade Infranet, define your custom fields in a separate header file and include that file in your application.
Handling transactions
Infranet provides three basic transaction opcodes:
PCM_OP_TRANS_OPEN()
PCM_OP_TRANS_ABORT()
PCM_OP_TRANS_COMMIT()
In your application, you can call PCM_OP_TRANS_OPEN() before calling an opcode and PCM_OP_TRANS_ABORT() or PCM_OP_TRANS_COMMIT() after the opcode calls. However, by default, all opcodes except the password opcodes are surrounded by transactions if transactions are not open when they are called.
Configuring your custom application
You must set up the following applications to access the same database:
The client application
At least one CM
At least one DM
The client application makes the connection by using the Infranet database number in all three configuration files: the application's, the CM's, and the DM's. The database number is arbitrary, but it is determined before the system is installed. Once the system is installed, you can't change this number because it is encoded in every storable object in the database.
The client application must use POIDs with the correct database number. The system routes storable object requests on the basis of POIDs, which include the database number.
In your custom application, use the database number returned by PCM_CONNECT(). If you are using PCM_CONTEXT_OPEN(), call PCM_GET_USERID() and then PIN_POID_GET_DB() on the POID.
Caution! Do not get the database number or the userid POID from the configuration file by calling pin_conf() in your application.
Creating a client application in C
You write client applications by using the PCM opcodes, which send and receive flists to the Infranet database. Each opcode has a corresponding input and return flist.
Flists are used to hold return values for two important reasons:
The macro call itself does not return a value.
An flist can contain an arbitrary number of fields and values that is frequently not known in advance.
Your custom applications must include the header files that correspond to the FM opcodes you use. Which file to include depends on which opcodes you use. The header file for base opcodes needs to be included if you are using only base opcodes, which is unlikely. For information on header files and a list of opcodes and their corresponding header files, see Header files.
You use the PCM_OP() macro to pass PCM opcodes and flists to Infranet. The system returns an flist. You create input flists for the call to PCM_OP() and routine returns the results in an flist. You use the return flists and then destroy them.
The following pseudo-code shows the format of most client programs:
#include "pcm.h"/* header file corresponding to the FM opcode you're using */#include "ops/file.h" #include "pin_errs.h" main() . . . /* open a database context */ PCM_CONTEXT_OPEN() /* clear error buffer */ PIN_ERRBUF_CLEAR(&ebuf); /* send opcode to system, based on user activity or application function. */
PCM_OP(input_flist, opcode, return_flist, &ebuf) /* check for errors */ if (PIN_ERRBUF_IS_ERR(&ebuf)) { /* handle error */ } else { /* ok - no errors */ } . . . /* close database context */ PCM_CONTEXT_CLOSE() . . . exit(0);
Compiling and linking your programs
You don't have to follow any special precompilation or other steps to compile and link applications. Both static and dynamic versions of Infranet libraries are provided.
UNIX client libraries are multi-thread safe. For special instructions on writing Infranet applications in a multi-threaded Windows environment, see Managing memory in a multithreaded Windows environment
To compile and link your application:
Compile using the include files in the Infranet_SDK_home/include directory.
Link to the libraries in Infranet_SDK_home/lib.
See the sample applications and their make files for more information.
The following compilers are supported:
Solaris: Standard SUNPro C compiler, default mode (-Xa).
Infranet is compiled with -xcg92
Note gcc is not supported. Use the -munaligned-doubles option to ensure proper linking.
AIX: cc or xlC for C; xlC for C++
HP-UX: Standard HP C compiler
Windows: Microsoft Visual C or C++ compiler
Guidelines for developing applications in C on Windows
Follow these guidelines to develop custom applications in C on Windows:
Use Microsoft Developer Studio 5.0 or 6.0.
Always build your applications with the multi-threaded DLL or debug multi-threaded DLL (even when producing an .exe file).
Include portal.dll at link time.
Do not mix debug and release versions of library directives. Debug libraries are appended with the letter d. For example the debug version of portal.dll is for example, portald.dll.
Add Infranet_SDK_home/include to the list of include file directories to search.
In the preprocessor directives, be sure to include the following symbols:
WIN32,PIN_USE_ANSI_HDRS
Be extremely careful when running multiple versions of Infranet clients on the same computer. One version of portal.dll does not necessarily work for all versions of Infranet. If an application picks up the wrong DLL (or the wrong DLL is already loaded by another application), you might see abnormal program terminations. For information on sharing memory objects across threads, see Managing memory in a multithreaded Windows environment.
Guidelines for developing applications in C on UNIX platforms
Follow these guidelines to develop custom applications in C on Solaris, AIX, and HP-UX:
Include libportal.so or libportal.sl at link time.
Add Infranet_SDK_home/include to the list of include file directories to search.
In the preprocessor directives, be sure to include the following symbol:
PIN_USE_ANSI_HDRS.
Using the sample applications
Infranet SDK includes sample applications and code as well as source code for policy FMs that you can refer to for coding examples.
Sample applications
Infranet SDK includes sample applications and code in C, C++, Java, PCM COM, and Perl. For a complete list of the sample applications, see Sample Programs.
Before you write your program, try compiling and linking copies of these programs to familiarize yourself with the system. These programs are located in Infranet_SDK_home/source/samples. This directory also includes a sample application configuration file.
Caution! Don't run the sample programs on a production system. Some programs fill the database with test storable objects. Remove the test storable objects before building your production system.
Policy FM source files
Infranet SDK includes the source code for all the policy opcodes. You can refer to them for Infranet coding examples. You can find the Customer Policy FM opcode source files in Infranet_SDK_home/source/sys. Each policy FM has its own directory containing the source files for the included opcodes as well as a make file and other support files.
For more information, see the Transaction Handling section on each opcode reference page and Context management opcodes.
Adding Branded Service Management to your application
Branded Service Management allows a single hosting Infranet site to support multiple virtual Infranet sites. Each virtual ISP is known as a brand and requires a secured view of its own data. At the same time, the hosting site maintains administrative oversight of the entire system, which may include many independent Infranet sites.
The brand as an independent virtual workspace
Two kinds of accounts exist in a branded service management setting: standard accounts and brand accounts. The brand account is a special entity that serves as a complete miniature Infranet system. Each brand accesses the database according to its own rules. To effectively implement brands, "data scoping" is required.
Data scoping
Data scoping is the ability to restrict database access so that only authorized users can access data and services. The concept of an account is essential to effective data scoping. Most objects are account-centric. For example, services and profiles are designed to be associated with an account. Events and pricing objects also "belong" to an account. Therefore, to implement data scoping in a Branded Service Management environment, all objects must be associated with an account.
Pointing a base level object to a brand account
To enforce scoping restrictions, the system associates all objects with an account. This association is done via the PIN_FLD_ACCOUNT_OBJ reference in the every base level object.
! Account object to which data belongsfield PIN_FLD_ACCOUNT_OBJ ( type = PIN_FLDT_POID, perms = MW,
Defining a brand account
There are two account types: standard accounts and brands. The following tag specifies the account type.
! Brand object or normal objectfield PIN_FLD_ACCOUNT_TYPE ( type = PIN_FLDT_ENUM
This flag is set when the account is created, and cannot be modified later. The flag can have one of two values:
For brand accounts: PIN_ACCOUNT_TYPE_BRAND
For standard accounts: PIN_ACCOUNT_TYPE_STANDARD
Providing access to brands
In a Branded Service Management environment, it's often necessary for an object to have distinct read and write access rules. For example, all members of a brand account may have read access to a pricing object while write access may be much more restricted. To meet this requirement two new fields have been added to each account object that define read and write access rules for the object. These fields are controlled by the system and filled in by the Data Manager with values specified in the data dictionary. These are:
PIN_FLD_READ ACCESS: describes who has permission to read data
PIN_FLD_WRITE_ACCESS: describes who has permission to modify data
Branding access permissions
The following table defines the permissions that can be assigned for read and write access:
Permission Description
Global
Any user can read or write the object. Many /config objects are globally readable.
Brand
Any user with brand access can read or write the object. For example, pricing objects, such as products and deals, are brand-readable.
Self
Only the brand owner can read or write the data. Pricing objects are self-writeable and brand-specific to prevent unauthorized changes to the price list.
Ancestral Lineage
The brand owner or any superior billing group leader can read or write the data. For example, /device objects have Ancestral Lineage write permissions.
Brand Lineage
The owner, or any superior billing group leader within the brand, can read or write the data. Used with many objects, including services, profiles, and events to ensure brand segregation and data privacy.
Providing access to pricing information
All pricing related objects available for system use are associated at the brand level. Therefore, Pricing FM opcodes only look for pricing objects associated with the brand.
Read access to pricing data
Each brand in an Infranet system maintains its own pricing data. Because everyone who accesses the brand should be able to read pricing information, objects related to pricing have read access set to the Brand Group Scope level. Thus objects of the following types are all of the type PIN_FLD_READ_ACCESS = B (brand): /product, /rate, /fold, /plan_list.
Write access to pricing data
Since the ability to modify pricing information is generally much more restricted, write access to pricing objects are set locally. This ensures that only the owner of the pricing object can modify pricing data.
Billing groups
Billing groups act as containers for grouping accounts. A billing group leader has access to all account data owned by the billing group, as well as information owned by any of the billing group members. Thus a group leader can look down an entire tree of billing groups and its associated accounts within the brand. In this way, billing groups are used as the primary mechanism for categorizing scoping classes.
Providing billing group access with an Access Control List (ACL)
A new group object, /group/acl, has been created to define access for the billing group. The group acl includes a list of group members along with a pointer to the brand account or accounts to which group members have access.
Managing custom applications
A host ISP may manage many brand accounts. Each brand may in turn have access to a variety of multi-brand applications. Infranet's client interface simplifies an administrator's task. Once a user enters an authorized login and password, Infranet displays a list of available brands. A user can then set the current connection scope by selecting a brand to customize.
Creating brands programmatically
Use the PCM_OP_CUST_COMMIT_CUSTOMER opcode to create a new brand account. This opcode creates and initializes /account and /service storable objects. Once the account has been created, the account type flag must be set:
! Brand object or normal objectfield PIN_FLD_ACCOUNT_TYPE ( type = PIN_FLDT_ENUM
This flag is set when the account is created, and cannot be modified later. The flag can have one of two values:
For brand accounts: PIN_ACCOUNT_TYPE_BRAND
For standard accounts: PIN_ACCOUNT_TYPE_STANDARD
Set the flag to PIN_ACCOUNT_TYPE_BRAND to specify this account as a brand.
Writing brand-aware applications
Applications can be customized to meet the requirements of a brand. To do this, the administrator must first retrieve a list of available brands and then set the connection scope to the specific brand to be customized.
Displaying a list of user authorized brands
Use the PCM_OP_PERM_GET_CREDENTIALS opcode to display a list of the brands which have access to an application. Usually this opcode is called at start-up time. After the user enters an authorized login and password, the system displays a list of brands which have access to the application along with the currently active brand and billing group.
Setting the current connection scope
Because each brand represents an independent virtual workspace with its own data and access rules, a user must select a single brand (or billing subgroup) with which to work. Use the PCM_OP_PERM_SET_CREDENTIALS opcode to set the current connection scope.
About adding multidatabase support to your applications
Infranet supports the ability to add multiple databases for the purpose of scaling your Infranet system. This document explains the programming considerations of creating an application to work with an Infranet system using multiple databases.
For instructions on installing a multidatabase system, see:
Installing a Multidatabase Infranet System on Windows
Installing a Multidatabase Infranet System on UNIX
For instructions on maintaining a multidatabase system, see Managing a Multidatabase Infranet System.
This section explains the topics you need to know before you design a new application, or enhance an existing program to take advantage of the Infranet multidatabase feature.
About working with multiple databases
Generally, making applications work with multiple databases isn't all that different from making them work with a single database.
Accounts are distributed across databases, but applications log in to the correct database for an account based on the login name and service type. When an application logs in to Infranet, it gets the database context for the account it logged in as. An event for the login session for that application is created in the database that hosts the account.
After the application has logged in, it has access to the entire Infranet database for reads and writes on all classes that are modifiable. In most cases, after an account context is established, all subsequent operations for the account are performed in the single database where the context was opened.
Creating accounts
The PCM_OP_CUST_COMMIT_CUSTOMER opcode has been enhanced to work with multiple databases. Use that opcode to create accounts just as you would for a single database system. This opcode uses the /config/distribution object created by using the load_config_dist utility to determine which database your account is created in.
You can specify which database new accounts should be created in by editing the multidatabase configuration file. For more information, see Setting database priorities.
Important Billing groups, including all accounts with the same brand, must reside in the same database.
Maintaining transactional integrity
Important Remember, once you find an account to modify data in, confine all operations possible to that database.
Although an application can connect to multiple databases and manipulate data in any database, a transaction can only manipulate data in a single database. To perform a transaction on more than one database, you must close the existing transaction, open a context to the other database, and open another transaction. An application that needs to perform the same operation on all accounts (such as billing or invoicing), should be run as a separate instance on each database.
You must use the database number returned by PCM_CONNECT or PCM_CONTEXT_OPEN for all transactions within the context you open. These opcodes pass in an account's username and return the database number for that account. To prevent losing transactional integrity, avoid opening contexts to multiple databases whenever possible.
The exception to this rule is the rare occasion when you need to access information in any of the pricing storable classes. Embedded in these classes is the account information (including database number) of the person who changed that information. All account references are exact references. Dealing with this information can require you to switch contexts to another database with a new call to PCM_CONNECT or PCM_CONTEXT_OPEN.
Working with replicated objects
In multidatabase systems, some objects are replicated in all databases to improve performance. Replicating objects allows applications to access information in the database where the context is opened. Replicated objects are read-only except in the primary database.
Many frequently accessed objects, such as /config objects, are replicated. You can obtain a list of the replicated database tables by running a SQL query against the primary database.
Note The SQL query returns a list of table names. Table names generally correspond closely to storable class and class and field names. You can find detailed SQL mapping information for storable classes by following the links in Storable Class Definitions.
To generate a list of replicated tables for Oracle and SQL Server:
Log into the primary database as pin.
% sqlplus pin/password@DatabaseAlias
Enter the following SQL command to generate a list of replicated tables:
SQL> select distinct table_name from md_static_objects_t;
Searching for accounts across databases
Searching for a single account
There are two opcodes you can use to locate a single account:
Use the PCM_OP_ACT_FIND opcode to locate an account based on the login and service type. This opcode finds and returns the account POID (including the correct database number) of a single account.
Use the PCM_OP_GLOBAL_SEARCH opcode to locate an account based on other account attributes. This opcode returns any fields that you specify on the input flist.
Searching for multiple accounts (global search)
Use the PCM_OP_GLOBAL_SEARCH opcodes to find and return the POIDs of multiple accounts across multiple databases at the same time. The global search opcodes can also be used to search for a set of objects that live in multiple databases. For example, all events from a particular day. See Searching for Objects in Infranet Databases for a complete discussion of searching for accounts across multiple databases.
Important Remember to use non-global searches for better performance whenever possible. After you get the results of a global search, you can improve your application's overall performance by dividing the database read and write operations among databases.
Finding out how many databases you have with testnap
Use the testnap testing utility to find out the number of databases that are connected to your Infranet system. The example below shows testnap being started, and then displaying the contents of an flist named 1. This flist is designed to match all root accounts. In the next step, this flist is passed into PCM_OP_GLOBAL_SEARCH (Opcode number 25) which searches all databases. In this final step, testnap searches all databases for their root accounts. There is only one root account (in the /service class) in each database, so the result of this search is a listing of all the databases currently connected to your Infranet system. In this case there are two: 0.0.0.1 and 0.0.0.2.
testnapinput flist:nap(10238)> d 10 PIN_FLD_POID POID [0] 0.0.0.1 /search -1 00 PIN_FLD_FLAGS INT [0] 00 PIN_FLD_TEMPLATE STR [0] "select X from /service where F1 like V1 and F2 = V2 "0 PIN_FLD_ARGS ARRAY [1]1 PIN_FLD_LOGIN STR [0] "root.0.0.0%"0 PIN_FLD_ARGS ARRAY [2]1 PIN_FLD_POID POID [0] 0.0.0.0 /service/pcm_client -1 00 PIN_FLD_RESULTS ARRAY [0]1 PIN_FLD_POID POID [0] NULL1 PIN_FLD_LOGIN STR [0] ""result:nap(10238)> XOP PCM_OP_GLOBAL_SEARCH 0 1XOP: opcode 25, flags 0# number of field entries allocated 3, used 30 PIN_FLD_POID POID [0] 0.0.0.1 /search -1 00 PIN_FLD_RESULTS ARRAY [0] allocated 2, used 21 PIN_FLD_POID POID [0] 0.0.0.2 /service/pcm_client 1 11 PIN_FLD_LOGIN STR [0] "root.0.0.0.2"0 PIN_FLD_RESULTS ARRAY [1] allocated 2, used 21 PIN_FLD_POID POID [0] 0.0.0.1 /service/pcm_client 1 11 PIN_FLD_LOGIN STR [0] "root.0.0.0.1"
Bill numbering
Applications must now avoid hard-coding billing numbers. Bill numbers are now coded to the database they were created in and Infranet relies on the new numbering scheme. The /data/sequence class still keeps track of billing numbers to ensure that they are all unique. This class has been enhanced to make sure that database numbers are unique across databases.
--------------------------------------------------------------------------------
About this document
About adding new client applications
Ways to add custom applications
Using existing system opcodes
Using custom opcodes
Using a custom Data Manager (DM)
Handling transactions
Configuring your custom application
Creating a client application in C
Compiling and linking your programs
Guidelines for developing applications in C on Windows
Guidelines for developing applications in C on UNIX platforms
Using the sample applications
Sample applications
Policy FM source files
Adding Branded Service Management to your application
The brand as an independent virtual workspace
Data scoping
Pointing a base level object to a brand account
Defining a brand account
Providing access to brands
Branding access permissions
Providing access to pricing information
Billing groups
Providing billing group access with an Access Control List (ACL)
Managing custom applications
Creating brands programmatically
Writing brand-aware applications
Displaying a list of user authorized brands
Setting the current connection scope
About adding multidatabase support to your applications
About working with multiple databases
Creating accounts
Maintaining transactional integrity
Working with replicated objects
Searching for accounts across databases
Searching for a single account
Searching for multiple accounts (global search)
Finding out how many databases you have with testnap
Bill numbering
--------------------------------------------------------------------------------
About this document
This section describes how to add new client applications and how these applications function within the Infranet® system. It includes general information about writing client applications in all supported languages as well as specific information about writing applications in C. The section also contains links to sample applications and their corresponding Makefiles.
To create a custom application that communicates with Infranet, you need to understand the following Infranet components:
Storable classes and storable objects
See Understanding Infranet Flists and Storable Classes.
Portal Object ID (POID) management routines
See Portal object ID (POID).
Flists and flist routines
See About flists.
PCM opcodes and the PIN library routines
See Understanding the PCM API and the PIN Library.
Error-handling routines
See Understanding API Error Handling and Logging.
About adding new client applications
Client applications can be virtually any type of program, including GUI-based tools, Web-based tools, network-enabled applications, batch jobs, cron jobs, and so on. You can write custom application programs to create, manipulate, delete, and display custom storable objects, which in turn implement a business policy.
The base Infranet system comes with a set of client applications that manipulate storable objects within the database. You may, however, require custom applications. The most common custom application captures external events of some type. These events are then submitted to Infranet, details of the event stored, and the event charges assessed if necessary.
For example, a Web hosting application needs to track the number of bytes downloaded and disk space used. This requires an application to analyze disk-space usage and send it to the Rating EM at the end of each month. This also requires a new event type and new policy code that picks the rate category or quantity for the event.
Web servers don't provide an API to display the web usage automatically, so you might want to write an application that looks at the Web log files and generates events in Infranet. Because of the potential number of records in the Web logs, you can aggregate the data externally, and then send the summary to Infranet as events daily or monthly.
Infranet includes a set of client libraries that make it easier to create custom applications. Existing Infranet applications use these client libraries. These libraries are supported on Solaris, AIX, HP-UX, Windows 95, Windows 98, Windows 2000, and Windows NT. For more information about the libraries, see About the Infranet client access libraries.
For guidelines on writing Windows applications, see Guidelines for developing applications in C on Windows.
Ways to add custom applications
You can use the following options when you add custom applications to Infranet:
Using existing system opcodes.
Using custom opcodes.
Using a custom Data Manager (DM).
Using existing system opcodes
You use the base opcodes to create, read, write, delete, and search storable objects. The base opcodes also provide programmatic access to transaction commands. More complex opcodes are implemented by the Facilities Modules (FMs). You use the policy opcodes to implement business decisions. These higher-level opcodes are translated by the FMs to base opcodes and sent to Data Managers (DMs) for processing.
For more information on the different categories of opcodes and how they are used, see Understanding the PCM API and the PIN Library.
In a client application, you use opcodes to record events such as purchasing a product, changing a credit limit, creating an account or service, changing customer information, charging for use of a resource, verifying a password, and looking up names and addresses.
In your application, you can call any of the Infranet opcodes without changing the Infranet system. You need to determine when to use a particular system opcode, what constitutes an event, and then call the appropriate opcode in your application.
Your application must include the header files corresponding to the opcodes you use. All FM opcodes include the header file for base opcodes, so you don't need to include it unless your application uses only base opcodes.
For a list of opcodes and their corresponding header files, see Header files.
Using custom opcodes
If the system opcodes don't provide the required functionality, you can create custom opcodes. However, you must implement your new opcodes in a custom FM and configure the custom FM with each Connection Manager (CM).
For the application to communicate with the custom FM, the application and the FM have to agree on the opcodes to pass and the contents of their input and output flists, error buffers, and flags. The custom FM translates the new opcodes into base opcodes. Then, it can send the opcodes directly to a DM, or it can call other opcodes implemented by the standard FMs.
For information on how to create a custom FM and link it to a CM, see Writing a Custom Facilities Module.
You call the custom opcodes in the same way with the same API by using PCM_OP() as the system opcode. Therefore, you must supply all the parameters, just as in the case of a system opcode.
Create a header file in which you define your custom opcodes. Include the header file in both the application and the custom FM source files. Compile the application and the custom FM with the new header file.
For examples of including opcodes in the header file, see pcm_ops.h in the Infranet_home/include directory.
Tip Defining your custom opcodes in a separate .h file helps you avoid updating FM header files when you upgrade to a new release of Infranet.
Using a custom Data Manager (DM)
Your application can communicate with a custom DM if the custom DM and the application agree on the semantics of the input and return flists.
You attach fields to the input flist that have meaning to the custom DM. These new fields act as opcodes to the custom DM. The return flist is the mirror image of the input flist in the sense that the application and custom storage manager agree on the meaning of the field-value pairs returned by the storage manager. The storage manager is responsible for setting error buffer values.
For information on creating and implementing a custom DM, see Writing a Custom Data Manager.
You create new fields with the PIN_MAKE_FLD macro. For information on the PIN_MAKE_FLD macro, see pcm.h in the Infranet_home/include directory for field value ranges and examples of PIN_MAKE_FLD.
Tip To avoid updating the Infranet.h files every time you upgrade Infranet, define your custom fields in a separate header file and include that file in your application.
Handling transactions
Infranet provides three basic transaction opcodes:
PCM_OP_TRANS_OPEN()
PCM_OP_TRANS_ABORT()
PCM_OP_TRANS_COMMIT()
In your application, you can call PCM_OP_TRANS_OPEN() before calling an opcode and PCM_OP_TRANS_ABORT() or PCM_OP_TRANS_COMMIT() after the opcode calls. However, by default, all opcodes except the password opcodes are surrounded by transactions if transactions are not open when they are called.
Configuring your custom application
You must set up the following applications to access the same database:
The client application
At least one CM
At least one DM
The client application makes the connection by using the Infranet database number in all three configuration files: the application's, the CM's, and the DM's. The database number is arbitrary, but it is determined before the system is installed. Once the system is installed, you can't change this number because it is encoded in every storable object in the database.
The client application must use POIDs with the correct database number. The system routes storable object requests on the basis of POIDs, which include the database number.
In your custom application, use the database number returned by PCM_CONNECT(). If you are using PCM_CONTEXT_OPEN(), call PCM_GET_USERID() and then PIN_POID_GET_DB() on the POID.
Caution! Do not get the database number or the userid POID from the configuration file by calling pin_conf() in your application.
Creating a client application in C
You write client applications by using the PCM opcodes, which send and receive flists to the Infranet database. Each opcode has a corresponding input and return flist.
Flists are used to hold return values for two important reasons:
The macro call itself does not return a value.
An flist can contain an arbitrary number of fields and values that is frequently not known in advance.
Your custom applications must include the header files that correspond to the FM opcodes you use. Which file to include depends on which opcodes you use. The header file for base opcodes needs to be included if you are using only base opcodes, which is unlikely. For information on header files and a list of opcodes and their corresponding header files, see Header files.
You use the PCM_OP() macro to pass PCM opcodes and flists to Infranet. The system returns an flist. You create input flists for the call to PCM_OP() and routine returns the results in an flist. You use the return flists and then destroy them.
The following pseudo-code shows the format of most client programs:
#include "pcm.h"/* header file corresponding to the FM opcode you're using */#include "ops/file.h" #include "pin_errs.h" main() . . . /* open a database context */ PCM_CONTEXT_OPEN() /* clear error buffer */ PIN_ERRBUF_CLEAR(&ebuf); /* send opcode to system, based on user activity or application function. */
PCM_OP(input_flist, opcode, return_flist, &ebuf) /* check for errors */ if (PIN_ERRBUF_IS_ERR(&ebuf)) { /* handle error */ } else { /* ok - no errors */ } . . . /* close database context */ PCM_CONTEXT_CLOSE() . . . exit(0);
Compiling and linking your programs
You don't have to follow any special precompilation or other steps to compile and link applications. Both static and dynamic versions of Infranet libraries are provided.
UNIX client libraries are multi-thread safe. For special instructions on writing Infranet applications in a multi-threaded Windows environment, see Managing memory in a multithreaded Windows environment
To compile and link your application:
Compile using the include files in the Infranet_SDK_home/include directory.
Link to the libraries in Infranet_SDK_home/lib.
See the sample applications and their make files for more information.
The following compilers are supported:
Solaris: Standard SUNPro C compiler, default mode (-Xa).
Infranet is compiled with -xcg92
Note gcc is not supported. Use the -munaligned-doubles option to ensure proper linking.
AIX: cc or xlC for C; xlC for C++
HP-UX: Standard HP C compiler
Windows: Microsoft Visual C or C++ compiler
Guidelines for developing applications in C on Windows
Follow these guidelines to develop custom applications in C on Windows:
Use Microsoft Developer Studio 5.0 or 6.0.
Always build your applications with the multi-threaded DLL or debug multi-threaded DLL (even when producing an .exe file).
Include portal.dll at link time.
Do not mix debug and release versions of library directives. Debug libraries are appended with the letter d. For example the debug version of portal.dll is for example, portald.dll.
Add Infranet_SDK_home/include to the list of include file directories to search.
In the preprocessor directives, be sure to include the following symbols:
WIN32,PIN_USE_ANSI_HDRS
Be extremely careful when running multiple versions of Infranet clients on the same computer. One version of portal.dll does not necessarily work for all versions of Infranet. If an application picks up the wrong DLL (or the wrong DLL is already loaded by another application), you might see abnormal program terminations. For information on sharing memory objects across threads, see Managing memory in a multithreaded Windows environment.
Guidelines for developing applications in C on UNIX platforms
Follow these guidelines to develop custom applications in C on Solaris, AIX, and HP-UX:
Include libportal.so or libportal.sl at link time.
Add Infranet_SDK_home/include to the list of include file directories to search.
In the preprocessor directives, be sure to include the following symbol:
PIN_USE_ANSI_HDRS.
Using the sample applications
Infranet SDK includes sample applications and code as well as source code for policy FMs that you can refer to for coding examples.
Sample applications
Infranet SDK includes sample applications and code in C, C++, Java, PCM COM, and Perl. For a complete list of the sample applications, see Sample Programs.
Before you write your program, try compiling and linking copies of these programs to familiarize yourself with the system. These programs are located in Infranet_SDK_home/source/samples. This directory also includes a sample application configuration file.
Caution! Don't run the sample programs on a production system. Some programs fill the database with test storable objects. Remove the test storable objects before building your production system.
Policy FM source files
Infranet SDK includes the source code for all the policy opcodes. You can refer to them for Infranet coding examples. You can find the Customer Policy FM opcode source files in Infranet_SDK_home/source/sys. Each policy FM has its own directory containing the source files for the included opcodes as well as a make file and other support files.
For more information, see the Transaction Handling section on each opcode reference page and Context management opcodes.
Adding Branded Service Management to your application
Branded Service Management allows a single hosting Infranet site to support multiple virtual Infranet sites. Each virtual ISP is known as a brand and requires a secured view of its own data. At the same time, the hosting site maintains administrative oversight of the entire system, which may include many independent Infranet sites.
The brand as an independent virtual workspace
Two kinds of accounts exist in a branded service management setting: standard accounts and brand accounts. The brand account is a special entity that serves as a complete miniature Infranet system. Each brand accesses the database according to its own rules. To effectively implement brands, "data scoping" is required.
Data scoping
Data scoping is the ability to restrict database access so that only authorized users can access data and services. The concept of an account is essential to effective data scoping. Most objects are account-centric. For example, services and profiles are designed to be associated with an account. Events and pricing objects also "belong" to an account. Therefore, to implement data scoping in a Branded Service Management environment, all objects must be associated with an account.
Pointing a base level object to a brand account
To enforce scoping restrictions, the system associates all objects with an account. This association is done via the PIN_FLD_ACCOUNT_OBJ reference in the every base level object.
! Account object to which data belongsfield PIN_FLD_ACCOUNT_OBJ ( type = PIN_FLDT_POID, perms = MW,
Defining a brand account
There are two account types: standard accounts and brands. The following tag specifies the account type.
! Brand object or normal objectfield PIN_FLD_ACCOUNT_TYPE ( type = PIN_FLDT_ENUM
This flag is set when the account is created, and cannot be modified later. The flag can have one of two values:
For brand accounts: PIN_ACCOUNT_TYPE_BRAND
For standard accounts: PIN_ACCOUNT_TYPE_STANDARD
Providing access to brands
In a Branded Service Management environment, it's often necessary for an object to have distinct read and write access rules. For example, all members of a brand account may have read access to a pricing object while write access may be much more restricted. To meet this requirement two new fields have been added to each account object that define read and write access rules for the object. These fields are controlled by the system and filled in by the Data Manager with values specified in the data dictionary. These are:
PIN_FLD_READ ACCESS: describes who has permission to read data
PIN_FLD_WRITE_ACCESS: describes who has permission to modify data
Branding access permissions
The following table defines the permissions that can be assigned for read and write access:
Permission Description
Global
Any user can read or write the object. Many /config objects are globally readable.
Brand
Any user with brand access can read or write the object. For example, pricing objects, such as products and deals, are brand-readable.
Self
Only the brand owner can read or write the data. Pricing objects are self-writeable and brand-specific to prevent unauthorized changes to the price list.
Ancestral Lineage
The brand owner or any superior billing group leader can read or write the data. For example, /device objects have Ancestral Lineage write permissions.
Brand Lineage
The owner, or any superior billing group leader within the brand, can read or write the data. Used with many objects, including services, profiles, and events to ensure brand segregation and data privacy.
Providing access to pricing information
All pricing related objects available for system use are associated at the brand level. Therefore, Pricing FM opcodes only look for pricing objects associated with the brand.
Read access to pricing data
Each brand in an Infranet system maintains its own pricing data. Because everyone who accesses the brand should be able to read pricing information, objects related to pricing have read access set to the Brand Group Scope level. Thus objects of the following types are all of the type PIN_FLD_READ_ACCESS = B (brand): /product, /rate, /fold, /plan_list.
Write access to pricing data
Since the ability to modify pricing information is generally much more restricted, write access to pricing objects are set locally. This ensures that only the owner of the pricing object can modify pricing data.
Billing groups
Billing groups act as containers for grouping accounts. A billing group leader has access to all account data owned by the billing group, as well as information owned by any of the billing group members. Thus a group leader can look down an entire tree of billing groups and its associated accounts within the brand. In this way, billing groups are used as the primary mechanism for categorizing scoping classes.
Providing billing group access with an Access Control List (ACL)
A new group object, /group/acl, has been created to define access for the billing group. The group acl includes a list of group members along with a pointer to the brand account or accounts to which group members have access.
Managing custom applications
A host ISP may manage many brand accounts. Each brand may in turn have access to a variety of multi-brand applications. Infranet's client interface simplifies an administrator's task. Once a user enters an authorized login and password, Infranet displays a list of available brands. A user can then set the current connection scope by selecting a brand to customize.
Creating brands programmatically
Use the PCM_OP_CUST_COMMIT_CUSTOMER opcode to create a new brand account. This opcode creates and initializes /account and /service storable objects. Once the account has been created, the account type flag must be set:
! Brand object or normal objectfield PIN_FLD_ACCOUNT_TYPE ( type = PIN_FLDT_ENUM
This flag is set when the account is created, and cannot be modified later. The flag can have one of two values:
For brand accounts: PIN_ACCOUNT_TYPE_BRAND
For standard accounts: PIN_ACCOUNT_TYPE_STANDARD
Set the flag to PIN_ACCOUNT_TYPE_BRAND to specify this account as a brand.
Writing brand-aware applications
Applications can be customized to meet the requirements of a brand. To do this, the administrator must first retrieve a list of available brands and then set the connection scope to the specific brand to be customized.
Displaying a list of user authorized brands
Use the PCM_OP_PERM_GET_CREDENTIALS opcode to display a list of the brands which have access to an application. Usually this opcode is called at start-up time. After the user enters an authorized login and password, the system displays a list of brands which have access to the application along with the currently active brand and billing group.
Setting the current connection scope
Because each brand represents an independent virtual workspace with its own data and access rules, a user must select a single brand (or billing subgroup) with which to work. Use the PCM_OP_PERM_SET_CREDENTIALS opcode to set the current connection scope.
About adding multidatabase support to your applications
Infranet supports the ability to add multiple databases for the purpose of scaling your Infranet system. This document explains the programming considerations of creating an application to work with an Infranet system using multiple databases.
For instructions on installing a multidatabase system, see:
Installing a Multidatabase Infranet System on Windows
Installing a Multidatabase Infranet System on UNIX
For instructions on maintaining a multidatabase system, see Managing a Multidatabase Infranet System.
This section explains the topics you need to know before you design a new application, or enhance an existing program to take advantage of the Infranet multidatabase feature.
About working with multiple databases
Generally, making applications work with multiple databases isn't all that different from making them work with a single database.
Accounts are distributed across databases, but applications log in to the correct database for an account based on the login name and service type. When an application logs in to Infranet, it gets the database context for the account it logged in as. An event for the login session for that application is created in the database that hosts the account.
After the application has logged in, it has access to the entire Infranet database for reads and writes on all classes that are modifiable. In most cases, after an account context is established, all subsequent operations for the account are performed in the single database where the context was opened.
Creating accounts
The PCM_OP_CUST_COMMIT_CUSTOMER opcode has been enhanced to work with multiple databases. Use that opcode to create accounts just as you would for a single database system. This opcode uses the /config/distribution object created by using the load_config_dist utility to determine which database your account is created in.
You can specify which database new accounts should be created in by editing the multidatabase configuration file. For more information, see Setting database priorities.
Important Billing groups, including all accounts with the same brand, must reside in the same database.
Maintaining transactional integrity
Important Remember, once you find an account to modify data in, confine all operations possible to that database.
Although an application can connect to multiple databases and manipulate data in any database, a transaction can only manipulate data in a single database. To perform a transaction on more than one database, you must close the existing transaction, open a context to the other database, and open another transaction. An application that needs to perform the same operation on all accounts (such as billing or invoicing), should be run as a separate instance on each database.
You must use the database number returned by PCM_CONNECT or PCM_CONTEXT_OPEN for all transactions within the context you open. These opcodes pass in an account's username and return the database number for that account. To prevent losing transactional integrity, avoid opening contexts to multiple databases whenever possible.
The exception to this rule is the rare occasion when you need to access information in any of the pricing storable classes. Embedded in these classes is the account information (including database number) of the person who changed that information. All account references are exact references. Dealing with this information can require you to switch contexts to another database with a new call to PCM_CONNECT or PCM_CONTEXT_OPEN.
Working with replicated objects
In multidatabase systems, some objects are replicated in all databases to improve performance. Replicating objects allows applications to access information in the database where the context is opened. Replicated objects are read-only except in the primary database.
Many frequently accessed objects, such as /config objects, are replicated. You can obtain a list of the replicated database tables by running a SQL query against the primary database.
Note The SQL query returns a list of table names. Table names generally correspond closely to storable class and class and field names. You can find detailed SQL mapping information for storable classes by following the links in Storable Class Definitions.
To generate a list of replicated tables for Oracle and SQL Server:
Log into the primary database as pin.
% sqlplus pin/password@DatabaseAlias
Enter the following SQL command to generate a list of replicated tables:
SQL> select distinct table_name from md_static_objects_t;
Searching for accounts across databases
Searching for a single account
There are two opcodes you can use to locate a single account:
Use the PCM_OP_ACT_FIND opcode to locate an account based on the login and service type. This opcode finds and returns the account POID (including the correct database number) of a single account.
Use the PCM_OP_GLOBAL_SEARCH opcode to locate an account based on other account attributes. This opcode returns any fields that you specify on the input flist.
Searching for multiple accounts (global search)
Use the PCM_OP_GLOBAL_SEARCH opcodes to find and return the POIDs of multiple accounts across multiple databases at the same time. The global search opcodes can also be used to search for a set of objects that live in multiple databases. For example, all events from a particular day. See Searching for Objects in Infranet Databases for a complete discussion of searching for accounts across multiple databases.
Important Remember to use non-global searches for better performance whenever possible. After you get the results of a global search, you can improve your application's overall performance by dividing the database read and write operations among databases.
Finding out how many databases you have with testnap
Use the testnap testing utility to find out the number of databases that are connected to your Infranet system. The example below shows testnap being started, and then displaying the contents of an flist named 1. This flist is designed to match all root accounts. In the next step, this flist is passed into PCM_OP_GLOBAL_SEARCH (Opcode number 25) which searches all databases. In this final step, testnap searches all databases for their root accounts. There is only one root account (in the /service class) in each database, so the result of this search is a listing of all the databases currently connected to your Infranet system. In this case there are two: 0.0.0.1 and 0.0.0.2.
testnapinput flist:nap(10238)> d 10 PIN_FLD_POID POID [0] 0.0.0.1 /search -1 00 PIN_FLD_FLAGS INT [0] 00 PIN_FLD_TEMPLATE STR [0] "select X from /service where F1 like V1 and F2 = V2 "0 PIN_FLD_ARGS ARRAY [1]1 PIN_FLD_LOGIN STR [0] "root.0.0.0%"0 PIN_FLD_ARGS ARRAY [2]1 PIN_FLD_POID POID [0] 0.0.0.0 /service/pcm_client -1 00 PIN_FLD_RESULTS ARRAY [0]1 PIN_FLD_POID POID [0] NULL1 PIN_FLD_LOGIN STR [0] ""result:nap(10238)> XOP PCM_OP_GLOBAL_SEARCH 0 1XOP: opcode 25, flags 0# number of field entries allocated 3, used 30 PIN_FLD_POID POID [0] 0.0.0.1 /search -1 00 PIN_FLD_RESULTS ARRAY [0] allocated 2, used 21 PIN_FLD_POID POID [0] 0.0.0.2 /service/pcm_client 1 11 PIN_FLD_LOGIN STR [0] "root.0.0.0.2"0 PIN_FLD_RESULTS ARRAY [1] allocated 2, used 21 PIN_FLD_POID POID [0] 0.0.0.1 /service/pcm_client 1 11 PIN_FLD_LOGIN STR [0] "root.0.0.0.1"
Bill numbering
Applications must now avoid hard-coding billing numbers. Bill numbers are now coded to the database they were created in and Infranet relies on the new numbering scheme. The /data/sequence class still keeps track of billing numbers to ensure that they are all unique. This class has been enhanced to make sure that database numbers are unique across databases.
--------------------------------------------------------------------------------
Monday, June 20, 2005
Kiwi weather n pee- pal
I can’t see clearly now …
We, the residents of Auckland and its suburbs, are experiencing winter in all its glory (read: fury!). It has been brutal. Temperature has “dipped” (I would have used the word plummeted) to 3 degree Celsius, according to Weather forecasting on SKY watch. If you are like me and numbers, positive or negative, don’t make much sense to your grey cells then maybe this would help “if you are outside without gloves for a few minutes your will experience frostbite.” All I want to do is hibernate.
As if the bone chilling wind wasn’t enough, there’s snow. And, when there is snow you can be rest assured no matter what road you are on in Auckland you are going to sit in it. Even turtles seem walking light years faster than your 6 cylinder, mega horsepower motorized vehicle. Day before yesterday, it took me 2 hours 45 minutes to reach work. By the time I reached, I was ready to turn back but decided to rest for a while and then make the arduous journey home.
Weather … cold or hot … is crucial to Kiwis. It is a great ice-breaker! If it were not for weather, I think many of us wouldn’t know what to talk about. Across local convenience stores and human lines outside washrooms in Mc donalds, people walk right up to you and say “It is cold, eh?” They reinforce the coldness, just in case you had failed to notice. “Yeah,” you nod as your water runs out of your nose and eyes.
“I heard it is going to go down even more tonight.”
“Really. Good Lord, can it get any worse.”
“Actually yes! I heard on the radio this weekend we will experience snow storm with winds gushing upto 60km/hr.”
“ Geez!”
“I know. I can’t remember it being this cold … over the last 6 months.” (It should be noted here that NZ actually does have 4 seasons)
”oh well, bundle up (read: look hideous) and enjoy. It ain’t gonna last forever."
"Yep. Before you know it will be spring" ... as you close the door of the public washroom at Mc donalds.
And, it is this last cheery note – hope - that keeps us here … together … rain or snow.
We, the residents of Auckland and its suburbs, are experiencing winter in all its glory (read: fury!). It has been brutal. Temperature has “dipped” (I would have used the word plummeted) to 3 degree Celsius, according to Weather forecasting on SKY watch. If you are like me and numbers, positive or negative, don’t make much sense to your grey cells then maybe this would help “if you are outside without gloves for a few minutes your will experience frostbite.” All I want to do is hibernate.
As if the bone chilling wind wasn’t enough, there’s snow. And, when there is snow you can be rest assured no matter what road you are on in Auckland you are going to sit in it. Even turtles seem walking light years faster than your 6 cylinder, mega horsepower motorized vehicle. Day before yesterday, it took me 2 hours 45 minutes to reach work. By the time I reached, I was ready to turn back but decided to rest for a while and then make the arduous journey home.
Weather … cold or hot … is crucial to Kiwis. It is a great ice-breaker! If it were not for weather, I think many of us wouldn’t know what to talk about. Across local convenience stores and human lines outside washrooms in Mc donalds, people walk right up to you and say “It is cold, eh?” They reinforce the coldness, just in case you had failed to notice. “Yeah,” you nod as your water runs out of your nose and eyes.
“I heard it is going to go down even more tonight.”
“Really. Good Lord, can it get any worse.”
“Actually yes! I heard on the radio this weekend we will experience snow storm with winds gushing upto 60km/hr.”
“ Geez!”
“I know. I can’t remember it being this cold … over the last 6 months.” (It should be noted here that NZ actually does have 4 seasons)
”oh well, bundle up (read: look hideous) and enjoy. It ain’t gonna last forever."
"Yep. Before you know it will be spring" ... as you close the door of the public washroom at Mc donalds.
And, it is this last cheery note – hope - that keeps us here … together … rain or snow.
Friday, June 17, 2005
Learning Infranet :-- FLISTS data structure
About flists :-
=========
An flist is the fundamental data structure used in Infranet. Flists (field lists) are containers that hold fields, each of which is a pair of data field name and its value.
Example:
LAST_NAME STR "Tripathi"
FIRST_NAME STR "Dharmesh"
COMPANY STR "IBM Global Services"
Infranet processes can interpret data only in an flist format. The storage manager in the Data Manager (DM) translates the flists to a format that the database can process, and then translates the data from the database into an flist before passing it to the Connection Manager (CM).
Infranet uses flists in these ways:
Storable objects are passed in the form of flists between opcodes or programs that manipulate the storable objects.
Opcodes use flists to pass data between the Infranet applications and the database. For each opcode, an input flist is passed to pcm_op() and the return flist is passed back from this routine.
Contents of an flist
In an flist, you can use any of the Infranet supported data types such as decimals, buffers, arrays, and substructures. Flists can contain any number of fields. You can nest flists to any level; that is, you can place flists within other flists.
For a description of the Infranet data types that you can use in an flist, see Understanding the Infranet Data Types. For a list of the data type abbreviations used in flists, see Flist field data types.
The following example shows a partial input flist for the PCM_OP_CUST_COMMIT_CUSTOMER opcode printed out:
Note [0] after the field type represents the element ID. The numbers 0, 1, 2, and so on at the beginning of each line indicate the nesting level of the field, 0 meaning the top level.
0 PIN_FLD_POID POID [0] 0.0.0.1 /plan 11950 0
0 PIN_FLD_CREATED_T TSTAMP [0] (937336272) 09/14/99 12:11:12
0 PIN_FLD_MOD_T TSTAMP [0] (937336272) 09/14/99 12:11:12
0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.1 /account -1 0
0 PIN_FLD_DEAL_OBJ POID [0] 0.0.0.0 0 0
0 PIN_FLD_DESCR STR [0] "IP with 10 Free hrs per month"
0 PIN_FLD_NAME STR [0] "Basic"0 PIN_FLD_LIMIT ARRAY [840] allocated 3, used 3
1 PIN_FLD_CREDIT_FLOOR NUM [0] 0.000000
1 PIN_FLD_CREDIT_LIMIT NUM [0] 100.000000
1 PIN_FLD_CREDIT_THRESHOLDS INT [0] 0
0 PIN_FLD_SERVICES ARRAY [0] allocated 4, used 4
1 PIN_FLD_DEAL_OBJ POID [0] 0.0.0.1 /deal 9390 0
1 PIN_FLD_SERVICE_OBJ POID [0] 0.0.0.1 /service/ip -1 0
1 PIN_FLD_LOGIN STR [0] "aac4"
1 PIN_FLD_PASSWD_CLEAR STR [0] "aac4"
0 PIN_FLD_NAMEINFO ARRAY [1] allocated 10, used 10
1 PIN_FLD_CONTACT_TYPE STR [0] "Billing"
1 PIN_FLD_LAST_NAME STR [0] "aac1"
1 PIN_FLD_FIRST_NAME STR [0] "aac1"
1 PIN_FLD_TITLE STR [0] "aac1"
1 PIN_FLD_COMPANY STR [0] "aac1"
1 PIN_FLD_ADDRESS STR [0] "aac1"
1 PIN_FLD_CITY STR [0] "aac1"
1 PIN_FLD_STATE STR [0] "CA"
1 PIN_FLD_ZIP STR [0] "99999"
1 PIN_FLD_COUNTRY STR [0] "USA"
0 PIN_FLD_BILLINFO ARRAY [1] allocated 3, used 3
1 PIN_FLD_ACCESS_CODE1 STR [0] "aac1"
1 PIN_FLD_ACCESS_CODE2 STR [0] "aac1"
1 PIN_FLD_BILL_TYPE ENUM [0] 10001
0 PIN_FLD_ACTGINFO ARRAY [1] allocated 0, used 0
0 PIN_FLD_LOCALES ARRAY [1] allocated 1, used 1
1 PIN_FLD_LOCALE STR [0] "ENU"
...
Flist field data types :-
================
When you include a field in an flist, you must also include an abbreviation of the field's data type. The following table lists the valid Infranet field types and their abbreviations.
Field Type Abbreviation :-
==================
PIN_FLDT_ARRAY :- ARRAY
PIN_FLDT_BINSTR :- BINSTR
PIN_FLDT_BUF :- BUF
PIN_FLDT_DECIMAL:- DECIMAL
PIN_FLDT_ENUM :- ENUM
PIN_FLDT_ERRBUF:- ERR
PIN_FLDT_INT:- INT
PIN_FLDT_POID:- POID
PIN_FLDT_STR:- STR
PIN_FLDT_SUBSTRUCT:- SUBSTRUCT
About creating and using an flist
=========================
You create and manipulate flists with the flist manipulation macros in the PIN library. You can add, remove, and modify fields in an flist by using the flist field manipulation macros. For more information see, Flist Management Macros and Flist Field-handling Macros.
Each opcode has an input and output flist specification. For each opcode you call, you need to create an flist for the data you want to pass in. When you create an input or an output flist for an opcode, follow the flist specifications for the opcode. See the flist specifications in the individual opcode descriptions. For access to opcode descriptions, see PCM Opcode Libraries. Drill down to the opcode you want.
Flists are dynamically allocated data structures. When a field is added to an flist, the field value is either already dynamically allocated in memory or is copied into dynamic memory as it is added.
Important :-You need to destroy the flist you create in your programs by calling PIN_FLIST_DESTROY() to reclaim the memory the flist occupied.
Macros or functions used for creating and managing FLISTs in INFRANET :-
==========================================================
Flist Management Macros
--------------------------------------------------------------------------------
PIN_FLIST_CREATE()
PIN_FLIST_DESTROY()
PIN_FLIST_DESTROY_EX()
PIN_FLIST_COUNT()
PIN_FLIST_COPY()
PIN_FLIST_CONCAT()
PIN_FLIST_SORT()
PIN_FLIST_SORT_REVERSE()
PIN_FLIST_PRINT()
PIN_FLIST_TO_STR()
PIN_STR_TO_FLIST()
PIN_FLIST_TO_XML()
--------------------------------------------------------------------------------
PIN_FLIST_CREATE()
Description
This Infranet macro creates an flist which is used to pass parameters to the PCM_OP() function. This routine creates an flist, and returns a pointer that is used to reference the flist by all future operations. All memory for the flist is dynamically allocated.
Synopsis
#include "pcm.h" pin_flist_t * PIN_FLIST_CREATE(ebufp) pin_errbuf_t *ebufp;
Parameters
ebufp
A pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns a pointer to the flist in the form of pin_flist_t*.
In the case of an error, NULL is returned.
Error handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_DESTROY()
Description
This macro destroys an flist. Flists use dynamically allocated memory, and they must be destroyed to free that memory. This routine destroys the entire contents of an flist, including all fields on the flist.
Note PIN_FLIST_DESTROY can destroy an flist, even if the ebufp is NULL.
Synopsis
#include "pcm.h"
void PIN_FLIST_DESTROY( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
*flistp
Pointer to the flist to destroy.
*ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Create an flist - PIN_FLIST_CREATE() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist onto another - PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_DESTROY_EX()
Description
This macro destroys an flist. Flists use dynamically allocated memory, and they must be destroyed to free that memory. This routine first checks whether the pointer passed in is NULL. If the pointer is NULL, it returns. If not NULL, then it destroys the entire contents of the flist, including all fields on the flist, and sets the flist pointer to NULL.
Note PIN_FLIST_DESTROY_EX can destroy an flist, even if the ebufp is NULL.
Synopsis
#include "pcm.h" void PIN_FLIST_DESTROY( pin_flist_t **flistpp; pin_errbuf_t *ebufp);
Parameters
**flistpp
Pointer to the flist to destroy.
*ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine uses the series ebuf style of error-handling. Applications can call any number of series ebuf-style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, because the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error-handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Create an flist - PIN_FLIST_CREATE() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist onto another - PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_COUNT()
Description
This macro counts the number of fields on the flist. Only fields on the main flist are included. Each array element and substruct are counted as a single element.
If PIN_FLIST_COUNT() is called with the pointer to an array element or substruct, the number of fields at that level of the flist is counted.
Synopsis
#include "pcm.h" int32 PIN_FLIST_COUNT( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to an flist to count the fields of.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns the number of fields as an unsigned integer. Returns zero in the case of an error.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist -PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another -PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string -PIN_FLIST_TO_STR()- Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_COPY()
Description
Copy an existing flist. The macro copies all levels of an flist, including its array elements and substructures. The copied fields and their values are duplicated so no memory is shared between the two flists.
Synopsis
#include "pcm.h"pin_flist_t *PIN_FLIST_COPY( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to be copied.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns a pointer to the new flist on completion.
Returns NULL in the case of an error.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_CONCAT()
Description
Concatenate one flist onto another. This macro appends a (source) flist to the end of another (destination) flist. No comparisons between the flists are performed, and the source flist remains unchanged.
Synopsis
#include "pcm.h" void PIN_FLIST_CONCAT( pin_flist_t *dest_flistp; pin_flist_t *src_flistp; pin_errbuf_t *ebufp);
Parameters
dest_flistp
Pointer to the destination flist.
src_flistp
Pointer to the source flist.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The function does not return a value; instead, the concatenated flist is returned in dest_flistp. If src_flistp is NULL, dest_flistp is returned unchanged. If dest_flistp is NULL, an error is returned in ebufp.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_SORT()
Description
This macro sorts flists, and is normally used to sort array elements. Arrays sorted may also be the result of a search.
The flist to be sorted usually represents an array of search results returned from PCM_OP_SEARCH. The sort_flistp parameter is an flist that you construct with the sort_parameter, called PIN_FLD_RESULTS. It would look like:
PIN_FLD_RESULTS field 1 field 2 . . .
Then use the sort_default parameter to compare non-existent fields to existing fields. If all of the result elements have field value(s), 0 can be passed as the value of sort_default.
In cases where a result element has a field value, and it is being compared to another result element with the same field, but no value:
A negative sort_default means that the result element with the missing field value is sorted before the other in the sorted list.
A positive sort_default means the missing field occurs after the other.
A sort_default of 0 means that they are considered equal and order is arbitrary on the sorted list.
Synopsis
#include "pcm.h" void PIN_FLIST_SORT( pin_flist_t *flistp; pin_flist_t *sort_listp; int32 sort_default; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist being sorted. The flist should normally consist of an array so that the sort is performed on elements of the array. Each element of the array may be a list of fields; it is those fields that get sorted. When you call this function, pass the exact array (flist) you want sorted, not the entire array.
sort_listp
List of fields in each element in flistp to use as sort fields. Elements in flistp are sorted in this order. If the value of this parameter is NULL, PIN_ERR_BAD_ARG is returned.
sort_default
The comparison to be used if an element is not found:
f1 NOT found, f2 found -> return sort_default
f1 found, f2 NOT found ->return -sort_default
f1 NOT found, f2 NOT found - > return 0 (equal)
a negative value for sort_default means: f1 < f2
a positive value for sort_default means: f1 > f2
a zero value for sort_default means: f1 == f2
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_SORT_REVERSE()
Description
Sort flists in reverse order. This opcode, along with PIN_FLIST_SORT() is normally used to sort array elements. Arrays sorted may also be the result of a search.
The flist to be sorted usually represents an array of search results returned from PCM_OP_SEARCH or PCM_OP_STEP_SEARCH. The sort_flistp parameter is an flist that you construct with the sort_parameter, called PIN_FLD_RESULTS. It would look like:
PIN_FLD_RESULTS field n . . . field 2 field 1
Then use the sort_default parameter to compare non-existent fields to existing fields. If all of the result elements have field value(s), 0 can be passed as the value of sort_default.
In cases where a result element has a field value, and it is being compared to another result element with the same field, but no value:
A negative sort_default means that the result element with the missing field value is sorted after the other in the sorted list.
A positive sort_default means the missing field occurs before the other.
A sort_default of 0 means that they are considered equal and order is arbitrary on the sorted list.
Synopsis
#include "pcm.h" void PIN_FLIST_SORT( pin_flist_t *flistp; pin_flist_t *sort_listp; int32 sort_default; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist being sorted. The flist should normally consist of an array so that the sort is performed on elements of the array. Each element of the array may be a list of fields; it is those fields that get sorted.
sort_listp
List of fields in each element in flistp to use as sort fields. Elements in flistp are sorted in this order. If the value of this parameter is NULL, PIN_ERR_BAD_ARG is returned.
sort_default
The comparison to be used if an element is not found:
a zero value for sort_default means: f1 == f2
a positive value for sort_default means: f1 > f2
a negative value for sort_default means: f1 < f2
f1 NOT found, f2 NOT found - > return 0 (equal)
f1 found, f2 NOT found ->return -sort_default
f1 NOT found, f2 found -> return sort_default
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Search for objects in a POD - PCM_OP_SEARCH - Opcode
Step search for objects in a POD - PCM_OP_STEP_SEARCH - Opcode
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_PRINT()
Description
This macro prints an flist to a file in ASCII format. All levels of the flist, including the contents of array elements and substructures, are printed. This is useful for debugging applications that build or manipulate flists.
Synopsis
#include "pcm.h" void PIN_FLIST_PRINT( pin_flist_t *flistp; FILE *fi; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to print.
fi
A pointer to a file to print a message to. If the value of this pointer is NULL, the message is printed to stdout.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_TO_STR()
Description
This macro prints the contents of an flist to a buffer in ASCII form.
Synopsis
#include "pcm.h" void PIN_FLIST_TO_STR( pin_flist_t *flistp; char **strpp; int32 *lenp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to print to a string.
strpp
A pointer to a buffer for the return string. If the value is NULL, a buffer is allocated using malloc.
lenp
The length of the buffer that strpp points to. The buffer must be large enough to include a \0. If the value of strpp is NULL, len is passed back as the size of the allocated buffer, excluding the \0.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The string is returned in strpp. If a buffer was allocated, len is the size of the string, excluding the NULL terminator. If a buffer is allocated, the application owns the memory and must free it eventually.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_STR_TO_FLIST()
Description
This macro take a string representation of an flist (for example, the output of PIN_FLIST_TO_STR()) and creates an flist run-time data structure.
Synopsis
#include "pcm.h" void PIN_STR_TO_FLIST( char *str; int64 default_db; pin_flist_t **flistp; pin_errbuf_t *ebufp);
Parameters
str
Pointer to a string containing an flist in ASCII form.
default_db
A specified database number. If the ASCII string contains the sub string "$DB", then the database number in this parameter will replace it.
flistp
Pointer to a buffer for the return flist.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The string is returned in flistp.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_TO_XML()
Description
This macro converts an flist to XML format. It is designed for converting an invoice to an XML format. The formatted XML invoice is generated directly from the flist. It ignores and doesn't convert data in buffer fields or fields of type PIN_FLDT_BINSTR.
Note This macro does not generate a .DTD file.
Synopsis
#include "pcm.h" void PIN_FLIST_TO_XML( pin_flist_t *flistp; int32 flags; int32 encoding; char **bufpp; int *lenp; char *root_elemname; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to convert.
flags
Specifies the name/attribute pairs to use for the XML element tag.
PIN_XML_BY_TYPE
Uses the TYPE field for the name of the XML element tag. This is the default.
PIN_XML_BY_NAME
Uses the field name for the name of the XML element tag.
PIN_XML_BY_SHORT_NAME
Uses the field name for the name of the XML element tag and drops the common prefix to include only the unique portion. For example, "PIN_FLD_NAME" becomes "NAME".
PIN_XML_FLDNO
Uses the field number for the attribute of the XML element tag.
PIN_XML_TYPE
Uses the TYPE field for the attribute of the XML element tag.
encoding
Specify UTF8.
bufpp
A pointer to the buffer that will contain the XML converted data.
lenp
The size of the buffer that bufpp points to.
root_elemname
The root element name. If you don't specify this field, the default root element name, "document", is used.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
--------------------------------------------------------------------------------
=========
An flist is the fundamental data structure used in Infranet. Flists (field lists) are containers that hold fields, each of which is a pair of data field name and its value.
Example:
LAST_NAME STR "Tripathi"
FIRST_NAME STR "Dharmesh"
COMPANY STR "IBM Global Services"
Infranet processes can interpret data only in an flist format. The storage manager in the Data Manager (DM) translates the flists to a format that the database can process, and then translates the data from the database into an flist before passing it to the Connection Manager (CM).
Infranet uses flists in these ways:
Storable objects are passed in the form of flists between opcodes or programs that manipulate the storable objects.
Opcodes use flists to pass data between the Infranet applications and the database. For each opcode, an input flist is passed to pcm_op() and the return flist is passed back from this routine.
Contents of an flist
In an flist, you can use any of the Infranet supported data types such as decimals, buffers, arrays, and substructures. Flists can contain any number of fields. You can nest flists to any level; that is, you can place flists within other flists.
For a description of the Infranet data types that you can use in an flist, see Understanding the Infranet Data Types. For a list of the data type abbreviations used in flists, see Flist field data types.
The following example shows a partial input flist for the PCM_OP_CUST_COMMIT_CUSTOMER opcode printed out:
Note [0] after the field type represents the element ID. The numbers 0, 1, 2, and so on at the beginning of each line indicate the nesting level of the field, 0 meaning the top level.
0 PIN_FLD_POID POID [0] 0.0.0.1 /plan 11950 0
0 PIN_FLD_CREATED_T TSTAMP [0] (937336272) 09/14/99 12:11:12
0 PIN_FLD_MOD_T TSTAMP [0] (937336272) 09/14/99 12:11:12
0 PIN_FLD_ACCOUNT_OBJ POID [0] 0.0.0.1 /account -1 0
0 PIN_FLD_DEAL_OBJ POID [0] 0.0.0.0 0 0
0 PIN_FLD_DESCR STR [0] "IP with 10 Free hrs per month"
0 PIN_FLD_NAME STR [0] "Basic"0 PIN_FLD_LIMIT ARRAY [840] allocated 3, used 3
1 PIN_FLD_CREDIT_FLOOR NUM [0] 0.000000
1 PIN_FLD_CREDIT_LIMIT NUM [0] 100.000000
1 PIN_FLD_CREDIT_THRESHOLDS INT [0] 0
0 PIN_FLD_SERVICES ARRAY [0] allocated 4, used 4
1 PIN_FLD_DEAL_OBJ POID [0] 0.0.0.1 /deal 9390 0
1 PIN_FLD_SERVICE_OBJ POID [0] 0.0.0.1 /service/ip -1 0
1 PIN_FLD_LOGIN STR [0] "aac4"
1 PIN_FLD_PASSWD_CLEAR STR [0] "aac4"
0 PIN_FLD_NAMEINFO ARRAY [1] allocated 10, used 10
1 PIN_FLD_CONTACT_TYPE STR [0] "Billing"
1 PIN_FLD_LAST_NAME STR [0] "aac1"
1 PIN_FLD_FIRST_NAME STR [0] "aac1"
1 PIN_FLD_TITLE STR [0] "aac1"
1 PIN_FLD_COMPANY STR [0] "aac1"
1 PIN_FLD_ADDRESS STR [0] "aac1"
1 PIN_FLD_CITY STR [0] "aac1"
1 PIN_FLD_STATE STR [0] "CA"
1 PIN_FLD_ZIP STR [0] "99999"
1 PIN_FLD_COUNTRY STR [0] "USA"
0 PIN_FLD_BILLINFO ARRAY [1] allocated 3, used 3
1 PIN_FLD_ACCESS_CODE1 STR [0] "aac1"
1 PIN_FLD_ACCESS_CODE2 STR [0] "aac1"
1 PIN_FLD_BILL_TYPE ENUM [0] 10001
0 PIN_FLD_ACTGINFO ARRAY [1] allocated 0, used 0
0 PIN_FLD_LOCALES ARRAY [1] allocated 1, used 1
1 PIN_FLD_LOCALE STR [0] "ENU"
...
Flist field data types :-
================
When you include a field in an flist, you must also include an abbreviation of the field's data type. The following table lists the valid Infranet field types and their abbreviations.
Field Type Abbreviation :-
==================
PIN_FLDT_ARRAY :- ARRAY
PIN_FLDT_BINSTR :- BINSTR
PIN_FLDT_BUF :- BUF
PIN_FLDT_DECIMAL:- DECIMAL
PIN_FLDT_ENUM :- ENUM
PIN_FLDT_ERRBUF:- ERR
PIN_FLDT_INT:- INT
PIN_FLDT_POID:- POID
PIN_FLDT_STR:- STR
PIN_FLDT_SUBSTRUCT:- SUBSTRUCT
About creating and using an flist
=========================
You create and manipulate flists with the flist manipulation macros in the PIN library. You can add, remove, and modify fields in an flist by using the flist field manipulation macros. For more information see, Flist Management Macros and Flist Field-handling Macros.
Each opcode has an input and output flist specification. For each opcode you call, you need to create an flist for the data you want to pass in. When you create an input or an output flist for an opcode, follow the flist specifications for the opcode. See the flist specifications in the individual opcode descriptions. For access to opcode descriptions, see PCM Opcode Libraries. Drill down to the opcode you want.
Flists are dynamically allocated data structures. When a field is added to an flist, the field value is either already dynamically allocated in memory or is copied into dynamic memory as it is added.
Important :-You need to destroy the flist you create in your programs by calling PIN_FLIST_DESTROY() to reclaim the memory the flist occupied.
Macros or functions used for creating and managing FLISTs in INFRANET :-
==========================================================
Flist Management Macros
--------------------------------------------------------------------------------
PIN_FLIST_CREATE()
PIN_FLIST_DESTROY()
PIN_FLIST_DESTROY_EX()
PIN_FLIST_COUNT()
PIN_FLIST_COPY()
PIN_FLIST_CONCAT()
PIN_FLIST_SORT()
PIN_FLIST_SORT_REVERSE()
PIN_FLIST_PRINT()
PIN_FLIST_TO_STR()
PIN_STR_TO_FLIST()
PIN_FLIST_TO_XML()
--------------------------------------------------------------------------------
PIN_FLIST_CREATE()
Description
This Infranet macro creates an flist which is used to pass parameters to the PCM_OP() function. This routine creates an flist, and returns a pointer that is used to reference the flist by all future operations. All memory for the flist is dynamically allocated.
Synopsis
#include "pcm.h" pin_flist_t * PIN_FLIST_CREATE(ebufp) pin_errbuf_t *ebufp;
Parameters
ebufp
A pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns a pointer to the flist in the form of pin_flist_t*.
In the case of an error, NULL is returned.
Error handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_DESTROY()
Description
This macro destroys an flist. Flists use dynamically allocated memory, and they must be destroyed to free that memory. This routine destroys the entire contents of an flist, including all fields on the flist.
Note PIN_FLIST_DESTROY can destroy an flist, even if the ebufp is NULL.
Synopsis
#include "pcm.h"
void PIN_FLIST_DESTROY( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
*flistp
Pointer to the flist to destroy.
*ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Create an flist - PIN_FLIST_CREATE() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist onto another - PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_DESTROY_EX()
Description
This macro destroys an flist. Flists use dynamically allocated memory, and they must be destroyed to free that memory. This routine first checks whether the pointer passed in is NULL. If the pointer is NULL, it returns. If not NULL, then it destroys the entire contents of the flist, including all fields on the flist, and sets the flist pointer to NULL.
Note PIN_FLIST_DESTROY_EX can destroy an flist, even if the ebufp is NULL.
Synopsis
#include "pcm.h" void PIN_FLIST_DESTROY( pin_flist_t **flistpp; pin_errbuf_t *ebufp);
Parameters
**flistpp
Pointer to the flist to destroy.
*ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine uses the series ebuf style of error-handling. Applications can call any number of series ebuf-style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, because the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error-handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Create an flist - PIN_FLIST_CREATE() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist onto another - PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_COUNT()
Description
This macro counts the number of fields on the flist. Only fields on the main flist are included. Each array element and substruct are counted as a single element.
If PIN_FLIST_COUNT() is called with the pointer to an array element or substruct, the number of fields at that level of the flist is counted.
Synopsis
#include "pcm.h" int32 PIN_FLIST_COUNT( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to an flist to count the fields of.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns the number of fields as an unsigned integer. Returns zero in the case of an error.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist -PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another -PIN_FLIST_CONCAT()- Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string -PIN_FLIST_TO_STR()- Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_COPY()
Description
Copy an existing flist. The macro copies all levels of an flist, including its array elements and substructures. The copied fields and their values are duplicated so no memory is shared between the two flists.
Synopsis
#include "pcm.h"pin_flist_t *PIN_FLIST_COPY( pin_flist_t *flistp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to be copied.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Returns a pointer to the new flist on completion.
Returns NULL in the case of an error.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_CONCAT()
Description
Concatenate one flist onto another. This macro appends a (source) flist to the end of another (destination) flist. No comparisons between the flists are performed, and the source flist remains unchanged.
Synopsis
#include "pcm.h" void PIN_FLIST_CONCAT( pin_flist_t *dest_flistp; pin_flist_t *src_flistp; pin_errbuf_t *ebufp);
Parameters
dest_flistp
Pointer to the destination flist.
src_flistp
Pointer to the source flist.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The function does not return a value; instead, the concatenated flist is returned in dest_flistp. If src_flistp is NULL, dest_flistp is returned unchanged. If dest_flistp is NULL, an error is returned in ebufp.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_SORT()
Description
This macro sorts flists, and is normally used to sort array elements. Arrays sorted may also be the result of a search.
The flist to be sorted usually represents an array of search results returned from PCM_OP_SEARCH. The sort_flistp parameter is an flist that you construct with the sort_parameter, called PIN_FLD_RESULTS. It would look like:
PIN_FLD_RESULTS field 1 field 2 . . .
Then use the sort_default parameter to compare non-existent fields to existing fields. If all of the result elements have field value(s), 0 can be passed as the value of sort_default.
In cases where a result element has a field value, and it is being compared to another result element with the same field, but no value:
A negative sort_default means that the result element with the missing field value is sorted before the other in the sorted list.
A positive sort_default means the missing field occurs after the other.
A sort_default of 0 means that they are considered equal and order is arbitrary on the sorted list.
Synopsis
#include "pcm.h" void PIN_FLIST_SORT( pin_flist_t *flistp; pin_flist_t *sort_listp; int32 sort_default; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist being sorted. The flist should normally consist of an array so that the sort is performed on elements of the array. Each element of the array may be a list of fields; it is those fields that get sorted. When you call this function, pass the exact array (flist) you want sorted, not the entire array.
sort_listp
List of fields in each element in flistp to use as sort fields. Elements in flistp are sorted in this order. If the value of this parameter is NULL, PIN_ERR_BAD_ARG is returned.
sort_default
The comparison to be used if an element is not found:
f1 NOT found, f2 found -> return sort_default
f1 found, f2 NOT found ->return -sort_default
f1 NOT found, f2 NOT found - > return 0 (equal)
a negative value for sort_default means: f1 < f2
a positive value for sort_default means: f1 > f2
a zero value for sort_default means: f1 == f2
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_SORT_REVERSE()
Description
Sort flists in reverse order. This opcode, along with PIN_FLIST_SORT() is normally used to sort array elements. Arrays sorted may also be the result of a search.
The flist to be sorted usually represents an array of search results returned from PCM_OP_SEARCH or PCM_OP_STEP_SEARCH. The sort_flistp parameter is an flist that you construct with the sort_parameter, called PIN_FLD_RESULTS. It would look like:
PIN_FLD_RESULTS field n . . . field 2 field 1
Then use the sort_default parameter to compare non-existent fields to existing fields. If all of the result elements have field value(s), 0 can be passed as the value of sort_default.
In cases where a result element has a field value, and it is being compared to another result element with the same field, but no value:
A negative sort_default means that the result element with the missing field value is sorted after the other in the sorted list.
A positive sort_default means the missing field occurs before the other.
A sort_default of 0 means that they are considered equal and order is arbitrary on the sorted list.
Synopsis
#include "pcm.h" void PIN_FLIST_SORT( pin_flist_t *flistp; pin_flist_t *sort_listp; int32 sort_default; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist being sorted. The flist should normally consist of an array so that the sort is performed on elements of the array. Each element of the array may be a list of fields; it is those fields that get sorted.
sort_listp
List of fields in each element in flistp to use as sort fields. Elements in flistp are sorted in this order. If the value of this parameter is NULL, PIN_ERR_BAD_ARG is returned.
sort_default
The comparison to be used if an element is not found:
a zero value for sort_default means: f1 == f2
a positive value for sort_default means: f1 > f2
a negative value for sort_default means: f1 < f2
f1 NOT found, f2 NOT found - > return 0 (equal)
f1 found, f2 NOT found ->return -sort_default
f1 NOT found, f2 found -> return sort_default
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Search for objects in a POD - PCM_OP_SEARCH - Opcode
Step search for objects in a POD - PCM_OP_STEP_SEARCH - Opcode
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_PRINT()
Description
This macro prints an flist to a file in ASCII format. All levels of the flist, including the contents of array elements and substructures, are printed. This is useful for debugging applications that build or manipulate flists.
Synopsis
#include "pcm.h" void PIN_FLIST_PRINT( pin_flist_t *flistp; FILE *fi; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to print.
fi
A pointer to a file to print a message to. If the value of this pointer is NULL, the message is printed to stdout.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Examples
The Sample Account Setup file is a C program that illustrates how to use this macro in the process of setting up a generic Portal account and service. The accompanying Makefile is also useful.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_TO_STR()
Description
This macro prints the contents of an flist to a buffer in ASCII form.
Synopsis
#include "pcm.h" void PIN_FLIST_TO_STR( pin_flist_t *flistp; char **strpp; int32 *lenp; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to print to a string.
strpp
A pointer to a buffer for the return string. If the value is NULL, a buffer is allocated using malloc.
lenp
The length of the buffer that strpp points to. The buffer must be large enough to include a \0. If the value of strpp is NULL, len is passed back as the size of the allocated buffer, excluding the \0.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The string is returned in strpp. If a buffer was allocated, len is the size of the string, excluding the NULL terminator. If a buffer is allocated, the application owns the memory and must free it eventually.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_STR_TO_FLIST()
Description
This macro take a string representation of an flist (for example, the output of PIN_FLIST_TO_STR()) and creates an flist run-time data structure.
Synopsis
#include "pcm.h" void PIN_STR_TO_FLIST( char *str; int64 default_db; pin_flist_t **flistp; pin_errbuf_t *ebufp);
Parameters
str
Pointer to a string containing an flist in ASCII form.
default_db
A specified database number. If the ASCII string contains the sub string "$DB", then the database number in this parameter will replace it.
flistp
Pointer to a buffer for the return flist.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
The string is returned in flistp.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
Convert an flist to XML - PIN_FLIST_TO_XML() - Macro
PIN_FLIST_TO_XML()
Description
This macro converts an flist to XML format. It is designed for converting an invoice to an XML format. The formatted XML invoice is generated directly from the flist. It ignores and doesn't convert data in buffer fields or fields of type PIN_FLDT_BINSTR.
Note This macro does not generate a .DTD file.
Synopsis
#include "pcm.h" void PIN_FLIST_TO_XML( pin_flist_t *flistp; int32 flags; int32 encoding; char **bufpp; int *lenp; char *root_elemname; pin_errbuf_t *ebufp);
Parameters
flistp
Pointer to the flist to convert.
flags
Specifies the name/attribute pairs to use for the XML element tag.
PIN_XML_BY_TYPE
Uses the TYPE field for the name of the XML element tag. This is the default.
PIN_XML_BY_NAME
Uses the field name for the name of the XML element tag.
PIN_XML_BY_SHORT_NAME
Uses the field name for the name of the XML element tag and drops the common prefix to include only the unique portion. For example, "PIN_FLD_NAME" becomes "NAME".
PIN_XML_FLDNO
Uses the field number for the attribute of the XML element tag.
PIN_XML_TYPE
Uses the TYPE field for the attribute of the XML element tag.
encoding
Specify UTF8.
bufpp
A pointer to the buffer that will contain the XML converted data.
lenp
The size of the buffer that bufpp points to.
root_elemname
The root element name. If you don't specify this field, the default root element name, "document", is used.
ebufp
Pointer to an error buffer. Used to pass status information back to the caller.
Return Values
Nothing is returned by this routine.
Error Handling
This routine utilizes the series ebuf style of error handling. Applications can call any number of series ebuf style API routines using the same ebuf, and only check for errors once at the end of the series of calls. This makes manipulating flists and POIDs much more efficient, since the entire logical operation can be completed, then tested once for any errors. See Understanding API Error Handling and Logging for details on error handling algorithms.
Related Information
Create an flist - PIN_FLIST_CREATE() - Macro
Destroy an flist - PIN_FLIST_DESTROY() - Macro
Destroy an flist - PIN_FLIST_DESTROY_EX() - Macro
Count fields on an flist - PIN_FLIST_COUNT() - Macro
Copy an flist - PIN_FLIST_COPY() - Macro
Concatenate one flist on another - PIN_FLIST_CONCAT() - Macro
Sort flists - PIN_FLIST_SORT() - Macro
Print an flist to a string - PIN_FLIST_TO_STR() - Macro
Print an flist - PIN_FLIST_PRINT() - Macro
--------------------------------------------------------------------------------
Thursday, June 02, 2005
My Latest Resume
Contact Details
Email id: dharmeshtripathi@engineer.com
Summary
Currently working with IBM Global Services (I) Pvt Ltd since November 2004 in
Telecommunications domain on billing system, Portal Infranet. Earlier I had been working with Patni Computers Systems Ltd for 2 years. I have done my B.E (Computer Science) from Birla Vishvakarma Mahavidyalaya, Sardar Patel University, Gujarat. I have always been an enthusiast for applying the knowledge and skills I have learned in this field for the development and progress of mankind. During my tenure at Patni Computer Systems, which is a SEI-CMMi Level5 organization and IBM Global Services (I) Ltd, which is a Fortune 500 organization; I have learned to manage processes and people working with me.
I am an Application Programmer and an Open systems development professional having Sound domain on Telecom Billing, functional experience in the design of relational database applications and the implementation and support of complex systems on Open systems technologies. Total software experience of 2 years and 6 months.
My technical abilities are complemented by sound communication and user interaction abilities.
Employers
Current Employer IBM Global Services (I) Pvt Ltd. (From Nov 2004 till date)
IBM strives to lead in the invention, development and manufacture of the industry's most advanced information technologies, including computer systems, software, storage systems and microelectronics.
IBM translates these advanced technologies into value for our customers through our professional solutions, services and consulting businesses worldwide.
Previous Employer Patni Computer Systems Ltd (From Nov 2002 to Nov 2004)
Systems Integration (Business skills)
• Successfully managed sign off, compliance, release processes and procedures for many systems integrators and projects including Patni Computers Systems Ltd , IBM Global Services, and Vodafone
• Successfully ran many customer workshops and customer presentations
• Authored many "systems integrations" documents such as Functional Specifications, Design Specifications and Interface Agreements.
• Experienced in interviewing and hiring outstanding project team members and contractors.
• Experienced in leading applications and teams.
Technical Skills
Language C, C++, Java, UNIX shell scripting and PL-SQL.
OS/Environment UNIX, Windows NT
Tools Autosys job scheduler, crontab jobs scheduler in Unix, Microsoft Visual Safe Source
Products/Applications
• Extremely familiar with Telco Billing Systems focusing mainly on Portal Infranet (over 1 years experience) and IntegRate (Billing system and Pipeline Rating Engine)
• Experienced with: BEA WebLogic, Apache, Tibco BusinessWorks, Tomcat, Microsoft Visio, Siebel, Siebel UAN, IPlanet, JRUN, IBM Websphere, Webmethods, WBI, Tivoli Work Scheduler
Professional Profile
Employer : IBM Global Services (I) Pvt Ltd.
Designation : Application Programmer
Date of Employment : Nov 2004 Till Date
Previous Employer : Patni Computer Systems Ltd.
Designation : Software Engineer
Date of Employment : Nov 2002 to Nov 2004.
Project Information
Project 1 Vodafone SAM Application (Asia Pacific-Australia, N Z and Fiji)
Employer IBM Global Services (I) Pvt Ltd
Type Maintenance, Enhancement
Title Programmer
Platform HP-UNIX
Application Portal Infranet 6.7
Technology/Software UNIX shell programming, Oracle and C, IScripts and Irules.
Client Vodafone Australia and New Zealand
Duration Dec 04 till date
Portal Infranet is a billing solution which serves as a complete, end-to-end billing solution for Vodafone Australia-New Zealand which is a communications and information service provider, enabling her to retain profitable customers, increase average revenue per user, quickly launch new and enhanced services, and leverage assets to increase shareholder value. With Portal Infranet, service providers can more effectively manage their core business and enhance its profitability while offering popular, higher-margin voice, data, and content services.
Responsibilities
• Detailed analysis and resolution of the issues regarding Rating, Billing of CDRs (Call Detail Records) files and providing end to end solutions.
• Performing Billing Systems Integration of Portal Infranet 6.7, Siebel and IBM WBI to Replace the legacy billing and customer management system (over 10 million total subscribers)
• Analysis, Bug –fixing of the tickets/issues regarding Rating, Billing, Invoice generating utilities (CMMPs, CMs, DMs).
• Maintenance of the Oracle database on the Infranet billing system, which manages the data for the customers’ information, their activity/usage information and product catalogs.
• Usage, analyses of the Client Tools for infranet like Pricing Center, Developer Center.
• Mentoring and guiding the infranet Production Support Team at Vodafone, Auckland in understanding the overall functionality of Infranet and Pipeline in detail.
• System Monitoring, alarm monitoring, Suspense Management, CDR reprocessing Revenue Assurance reporting.
Project Information
Project 2 Alliance GEN III
Employer Patni Computer Systems Limited, India
Type Development, Maintenance.
Title Programmer
Platform Windows NT 4.0 Server, UNIX Sun Solaris
Technology/Software PL-SQL, and C.
Client General Electric Card Services, USA.
GE CARD Services is involved in the business of credit card services to its customers. It uses various operational systems consisting of Oracle Databases at the backend and GUI at the front-end. To enable its managers to make better decisions, the company maintains a database for its customers, which consists of various tables and views. The Alliance GEN III project involves the design, development, and testing and ongoing maintenance of these databases. Specifically it involved the automation of process of loading records from flat files received from an existing GE mainframe server into the Alliance Oracle table on daily basis. I was a part of the team. I had taken up the role of coordinating technical requirements, design document creation, coding and testing.
Responsibilities
• Detailed analysis of the requirements.
• Map the user requirements with the operational systems.
• Design the tables using schemas.
• Develop the extract in C language , and required views and tables in PL-SQL
Project Information
Project 3 Amex Chargeback
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX
Technology/Software C, UNIX shell scripts, PL-SQL
Duration
Client GE Card services
The scope of this project is to Digitize and standardize the process for ticket retrievals and chargebacks for AMEX (a client for General Electric). It involved accepting for file feeds from AMEX (a third party server) providing ticket retrieval information to a UNIX server and transferring it to a Mainframe server.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing.
Project Information
Project 4 Software Currency
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX
Technology/Software C, UNIX shell scripts, PL-SQL
Duration Nov 2003 to May 2003
Client GE Card services
The scope of the project is to upgrade all midrange system software and corresponding applications to vendor supported releases (from ORACLE 7i to ORACLE 9i and Unix version sun solaris 5.5 to 5.8 ) in order to deliver environments that are fully supported by vendors and compatible among all system software including the Unix scheduler crontab to AUTOSYS .My team along with the GE Consumer Finance business will be involved to install/upgrade software, convert application codes, perform application testing and migrate development, QA and production system.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing
Project Information
Project 5 AFFN/Accel PIN Debit Cards
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX shell programming
Technology/Software C, UNIX shell scripts, PL-SQL
Duration
Client GE Card services
The purpose of this project is to transfer the monthly and daily reports available on the FiServ (a third party UNIX server) to DMZ (UNIX server) mainframe server and pushing it to another Transit (UNIX) server using FTP scripts and UNIX shell scripts. Finally the scripts are push to Mainframe server using ndm scripts.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing.
Tools
Autosys JOB Scheduler:-
Unicenter Autosys Job Management Web interface 4.5 is web-based portal by Computer Associates International, Inc. I have used its different features that monitor, manage and control the jobs on UNIX servers. The following features have been extensively used throughout different projects:-
• Monitoring, administrating, and reporting of jobs.
• Alarm monitoring and managing across multiple instances.
• Sent event Actions and reporting from graphical views.
• Monitor Event Process Log.
• Job run statistical report.
Technical Memberships:-
I have been an Active member and giving Online help for programmers on the following forums.
1.) Unix Discussions forums
2.)Autosys job scheduling discussions forums
Achievements
Runner up: - Inter-house Table tennis tournament at Gnyan Dham School Vapi.
Runner up: - Inter college G.K QUIZ competition
Runner up: - Club Patni annual carom tournament at Patni Computers systems Ltd.
Our team was recognized as a Dream Team Award winner at Patni Computers systems Ltd.
Was ranked in top 8% out of the 125,000 appeared in the Common Admission Test (CAT) conducted by the Indian Institute Managements.
Education
I have done my B.E (Computer Science) and secured first class percentage marks from Birla Vishwakarma Mahavidyalaya, Sardar Patel University, Gujarat.
Email id: dharmeshtripathi@engineer.com
Summary
Currently working with IBM Global Services (I) Pvt Ltd since November 2004 in
Telecommunications domain on billing system, Portal Infranet. Earlier I had been working with Patni Computers Systems Ltd for 2 years. I have done my B.E (Computer Science) from Birla Vishvakarma Mahavidyalaya, Sardar Patel University, Gujarat. I have always been an enthusiast for applying the knowledge and skills I have learned in this field for the development and progress of mankind. During my tenure at Patni Computer Systems, which is a SEI-CMMi Level5 organization and IBM Global Services (I) Ltd, which is a Fortune 500 organization; I have learned to manage processes and people working with me.
I am an Application Programmer and an Open systems development professional having Sound domain on Telecom Billing, functional experience in the design of relational database applications and the implementation and support of complex systems on Open systems technologies. Total software experience of 2 years and 6 months.
My technical abilities are complemented by sound communication and user interaction abilities.
Employers
Current Employer IBM Global Services (I) Pvt Ltd. (From Nov 2004 till date)
IBM strives to lead in the invention, development and manufacture of the industry's most advanced information technologies, including computer systems, software, storage systems and microelectronics.
IBM translates these advanced technologies into value for our customers through our professional solutions, services and consulting businesses worldwide.
Previous Employer Patni Computer Systems Ltd (From Nov 2002 to Nov 2004)
Systems Integration (Business skills)
• Successfully managed sign off, compliance, release processes and procedures for many systems integrators and projects including Patni Computers Systems Ltd , IBM Global Services, and Vodafone
• Successfully ran many customer workshops and customer presentations
• Authored many "systems integrations" documents such as Functional Specifications, Design Specifications and Interface Agreements.
• Experienced in interviewing and hiring outstanding project team members and contractors.
• Experienced in leading applications and teams.
Technical Skills
Language C, C++, Java, UNIX shell scripting and PL-SQL.
OS/Environment UNIX, Windows NT
Tools Autosys job scheduler, crontab jobs scheduler in Unix, Microsoft Visual Safe Source
Products/Applications
• Extremely familiar with Telco Billing Systems focusing mainly on Portal Infranet (over 1 years experience) and IntegRate (Billing system and Pipeline Rating Engine)
• Experienced with: BEA WebLogic, Apache, Tibco BusinessWorks, Tomcat, Microsoft Visio, Siebel, Siebel UAN, IPlanet, JRUN, IBM Websphere, Webmethods, WBI, Tivoli Work Scheduler
Professional Profile
Employer : IBM Global Services (I) Pvt Ltd.
Designation : Application Programmer
Date of Employment : Nov 2004 Till Date
Previous Employer : Patni Computer Systems Ltd.
Designation : Software Engineer
Date of Employment : Nov 2002 to Nov 2004.
Project Information
Project 1 Vodafone SAM Application (Asia Pacific-Australia, N Z and Fiji)
Employer IBM Global Services (I) Pvt Ltd
Type Maintenance, Enhancement
Title Programmer
Platform HP-UNIX
Application Portal Infranet 6.7
Technology/Software UNIX shell programming, Oracle and C, IScripts and Irules.
Client Vodafone Australia and New Zealand
Duration Dec 04 till date
Portal Infranet is a billing solution which serves as a complete, end-to-end billing solution for Vodafone Australia-New Zealand which is a communications and information service provider, enabling her to retain profitable customers, increase average revenue per user, quickly launch new and enhanced services, and leverage assets to increase shareholder value. With Portal Infranet, service providers can more effectively manage their core business and enhance its profitability while offering popular, higher-margin voice, data, and content services.
Responsibilities
• Detailed analysis and resolution of the issues regarding Rating, Billing of CDRs (Call Detail Records) files and providing end to end solutions.
• Performing Billing Systems Integration of Portal Infranet 6.7, Siebel and IBM WBI to Replace the legacy billing and customer management system (over 10 million total subscribers)
• Analysis, Bug –fixing of the tickets/issues regarding Rating, Billing, Invoice generating utilities (CMMPs, CMs, DMs).
• Maintenance of the Oracle database on the Infranet billing system, which manages the data for the customers’ information, their activity/usage information and product catalogs.
• Usage, analyses of the Client Tools for infranet like Pricing Center, Developer Center.
• Mentoring and guiding the infranet Production Support Team at Vodafone, Auckland in understanding the overall functionality of Infranet and Pipeline in detail.
• System Monitoring, alarm monitoring, Suspense Management, CDR reprocessing Revenue Assurance reporting.
Project Information
Project 2 Alliance GEN III
Employer Patni Computer Systems Limited, India
Type Development, Maintenance.
Title Programmer
Platform Windows NT 4.0 Server, UNIX Sun Solaris
Technology/Software PL-SQL, and C.
Client General Electric Card Services, USA.
GE CARD Services is involved in the business of credit card services to its customers. It uses various operational systems consisting of Oracle Databases at the backend and GUI at the front-end. To enable its managers to make better decisions, the company maintains a database for its customers, which consists of various tables and views. The Alliance GEN III project involves the design, development, and testing and ongoing maintenance of these databases. Specifically it involved the automation of process of loading records from flat files received from an existing GE mainframe server into the Alliance Oracle table on daily basis. I was a part of the team. I had taken up the role of coordinating technical requirements, design document creation, coding and testing.
Responsibilities
• Detailed analysis of the requirements.
• Map the user requirements with the operational systems.
• Design the tables using schemas.
• Develop the extract in C language , and required views and tables in PL-SQL
Project Information
Project 3 Amex Chargeback
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX
Technology/Software C, UNIX shell scripts, PL-SQL
Duration
Client GE Card services
The scope of this project is to Digitize and standardize the process for ticket retrievals and chargebacks for AMEX (a client for General Electric). It involved accepting for file feeds from AMEX (a third party server) providing ticket retrieval information to a UNIX server and transferring it to a Mainframe server.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing.
Project Information
Project 4 Software Currency
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX
Technology/Software C, UNIX shell scripts, PL-SQL
Duration Nov 2003 to May 2003
Client GE Card services
The scope of the project is to upgrade all midrange system software and corresponding applications to vendor supported releases (from ORACLE 7i to ORACLE 9i and Unix version sun solaris 5.5 to 5.8 ) in order to deliver environments that are fully supported by vendors and compatible among all system software including the Unix scheduler crontab to AUTOSYS .My team along with the GE Consumer Finance business will be involved to install/upgrade software, convert application codes, perform application testing and migrate development, QA and production system.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing
Project Information
Project 5 AFFN/Accel PIN Debit Cards
Employer Patni Computer Systems Ltd
Type Maintenance - Enhancement
Role Programmer
Platform UNIX shell programming
Technology/Software C, UNIX shell scripts, PL-SQL
Duration
Client GE Card services
The purpose of this project is to transfer the monthly and daily reports available on the FiServ (a third party UNIX server) to DMZ (UNIX server) mainframe server and pushing it to another Transit (UNIX) server using FTP scripts and UNIX shell scripts. Finally the scripts are push to Mainframe server using ndm scripts.
Responsibilities:
• Detailed analysis of the requirements.
• Creation of Design Documents.
• Coding
• Creating Test Cases and testing.
Tools
Autosys JOB Scheduler:-
Unicenter Autosys Job Management Web interface 4.5 is web-based portal by Computer Associates International, Inc. I have used its different features that monitor, manage and control the jobs on UNIX servers. The following features have been extensively used throughout different projects:-
• Monitoring, administrating, and reporting of jobs.
• Alarm monitoring and managing across multiple instances.
• Sent event Actions and reporting from graphical views.
• Monitor Event Process Log.
• Job run statistical report.
Technical Memberships:-
I have been an Active member and giving Online help for programmers on the following forums.
1.) Unix Discussions forums
2.)Autosys job scheduling discussions forums
Achievements
Runner up: - Inter-house Table tennis tournament at Gnyan Dham School Vapi.
Runner up: - Inter college G.K QUIZ competition
Runner up: - Club Patni annual carom tournament at Patni Computers systems Ltd.
Our team was recognized as a Dream Team Award winner at Patni Computers systems Ltd.
Was ranked in top 8% out of the 125,000 appeared in the Common Admission Test (CAT) conducted by the Indian Institute Managements.
Education
I have done my B.E (Computer Science) and secured first class percentage marks from Birla Vishwakarma Mahavidyalaya, Sardar Patel University, Gujarat.
Subscribe to:
Posts (Atom)
