Cost Statement:
15 years ago
Thursday, June 24, 2010
Sunday, June 20, 2010
SOFTWARE TESTING, QUALITY ASSURANCE
When ? Why?
QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.
Software Testing
Software testing is oriented to "detection". It's examining a system or an application under controlled conditions. It's intentionally making things go wrong when they should not and things happen when they should not.
QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.
Software Testing
Software testing is oriented to "detection". It's examining a system or an application under controlled conditions. It's intentionally making things go wrong when they should not and things happen when they should not.
Software Quality
Quality software is reasonably bug free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.
Software Verification and Validation
Verification is "whether the actual requirements are correctly implemented" and validation is code testing. Verification involves reviews, meetings, evaluating documents, plans, code, inspections, specifications etc. Validation occurs after verification and it's the actual testing to find defects against the functionality or the specifications.
Test Plan
Test Plan is a document that describes the objectives, scope, approach, and focus of a software testing effort.
Test Case
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
Good Software Coding
Good code is code that works according to the requirements, bug free, readable, expandable in the future and easily maintainable.
Good Design
In good design, the overall structure is clear, understandable, easily modifiable, and maintainable. Works correctly when implemented and functionality can be traced back to customer and end user requirements.
Good Test Engineer
Good test engineer has the ability to think the unthinkable, has the test to break attitute, strong desire to quality and attention to detail.
Walkthrough
Walkthrough is quick and informal meeting for evaluation purposes.
Software Life Cycle
The Software Life Cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
Software Inspection
The purpose of inspection is trying to find defects and problems mostly in documents such as test plans, specifications, test cases, coding etc. It helps to find the problems and report it but not to fix it. It is one of the most cost effective methods of software quality. Many people can join the inspections but normally one moderator, one reader and one note taker are mandatory.
Benefits of Automated Testing
It's very valuable for long term and on going projects. You can automize some or all of the tests which needs to be run from time to time repeatedly or diffucult to test manually. It saves time and effort, also makes testing possible out of working hours and nights. They can be used by different people and many times in the future. By this way, you also standardize the testing process and you can depend on the results.
Main problems of working in a geographically distributed team
The main problem is the communication. To know the team members, sharing as much information as possible whenever you need is very valuable to solve the problems and concerns. On the other hand, increasing the wired communication as much as possible, seting up meetings help to reduce the miscommunication problems.
Common problems in Software Development Process
Poor requirements, unrealistic schedule, inadequate testing, miscommunication and additional requirement changes after development begin.
Different Kind of Testing
• Black box testing : You don't need to know the internal design in detail or have a good knowledge about the code for this test. It's mainly based on functionality and specifications, requirements.
• White box testing : This test is based on detailed knowledged of the internal design and code. Tests are performed for specific code statements and coding styles.
• Unit testing : The most micro scale of testing to test specific functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code, may require developing test driver modules or test harnesses.
• Incremental integration testing : Continuous testing of an application as new functionality is added. Requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed. Done by programmers or by testers.
• Integration testing : Testing of combined parts of an application to determine if they function together correctly. It can be any type of application which has several independent sub applications, modules.
• Functional testing : Black box type testing to test the functional requirements of an application. Typically done by software testers but software programmers should also check if their code works before releasing it.
• System testing : Black box type testing that is based on overall requirements specifications. Covers all combined parts of a system.
• End to End testing : It's similar to system testing. Involves testing of a complete application environment similar to real world use. May require interacting with a database, using network communications, or interacting with other hardware, applications, or systems.
• Sanity testing or smoke testing : An initial testing effort to determine if a new sw version is performing well enough to start for a major software testing. For example, if the new software is crashing frequently or corrupting databases then it is not a good idea to start testing before all these problems are solved first.
• Regression testing : Re-testing after software is updated to fix some problems. The challenge might be to determine what needs to be tested, and all the interactions of the functions, especially near the end of the sofware cycle. Automated testing can be useful for this type of testing.
• Acceptance testing : This is the final testing done based on the agrements with the customer.
• Load / stress / performance testing : Testing an application under heavy loads. Such as simulating a very heavy traffic condition in a voice or data network, or a web site to determine at what point the system start causing problems or fails.
• Usability testing : Testing to determine how user friendly the application is. It depends on the end user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
• Install / Uninstall testing : Testing of full, partial, or upgrade install / uninstall processes.
• Recovery / failover testing : Testing to determine how well a system recovers from crashes, failures, or other major problems.
• Security testing : Testing to determine how well the system protects itself against unauthorized internal or external access and intentional damage. May require sophisticated testing techniques.
• Compatability testing : Testing how well software performs in different environments. Particular hardware, software, operating system, network environment etc. Like testing a web site in different browsers and browser versions.
• Exploratory testing : Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
• Ad-hoc testing : Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
• Context driven testing : Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life critical medical equipment software would be completely different than that for a low cost computer game.
• Comparison testing : Comparing software weaknesses and strengths to competing products.
• Alpha testing : Testing of an application when development is nearing completion. Minor design changes may still be made as a result of such testing. Typically done by end users or others, not by programmers or testers.
• Beta testing : Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end users or others, not by programmers or testers.
• Mutation testing : A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (defects) and retesting with the original test data/cases to determine if the defects are detected. Proper implementation requires large computational resources.
Quality software is reasonably bug free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.
Software Verification and Validation
Verification is "whether the actual requirements are correctly implemented" and validation is code testing. Verification involves reviews, meetings, evaluating documents, plans, code, inspections, specifications etc. Validation occurs after verification and it's the actual testing to find defects against the functionality or the specifications.
Test Plan
Test Plan is a document that describes the objectives, scope, approach, and focus of a software testing effort.
Test Case
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
Good Software Coding
Good code is code that works according to the requirements, bug free, readable, expandable in the future and easily maintainable.
Good Design
In good design, the overall structure is clear, understandable, easily modifiable, and maintainable. Works correctly when implemented and functionality can be traced back to customer and end user requirements.
Good Test Engineer
Good test engineer has the ability to think the unthinkable, has the test to break attitute, strong desire to quality and attention to detail.
Walkthrough
Walkthrough is quick and informal meeting for evaluation purposes.
Software Life Cycle
The Software Life Cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
Software Inspection
The purpose of inspection is trying to find defects and problems mostly in documents such as test plans, specifications, test cases, coding etc. It helps to find the problems and report it but not to fix it. It is one of the most cost effective methods of software quality. Many people can join the inspections but normally one moderator, one reader and one note taker are mandatory.
Benefits of Automated Testing
It's very valuable for long term and on going projects. You can automize some or all of the tests which needs to be run from time to time repeatedly or diffucult to test manually. It saves time and effort, also makes testing possible out of working hours and nights. They can be used by different people and many times in the future. By this way, you also standardize the testing process and you can depend on the results.
Main problems of working in a geographically distributed team
The main problem is the communication. To know the team members, sharing as much information as possible whenever you need is very valuable to solve the problems and concerns. On the other hand, increasing the wired communication as much as possible, seting up meetings help to reduce the miscommunication problems.
Common problems in Software Development Process
Poor requirements, unrealistic schedule, inadequate testing, miscommunication and additional requirement changes after development begin.
Different Kind of Testing
• Black box testing : You don't need to know the internal design in detail or have a good knowledge about the code for this test. It's mainly based on functionality and specifications, requirements.
• White box testing : This test is based on detailed knowledged of the internal design and code. Tests are performed for specific code statements and coding styles.
• Unit testing : The most micro scale of testing to test specific functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code, may require developing test driver modules or test harnesses.
• Incremental integration testing : Continuous testing of an application as new functionality is added. Requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed. Done by programmers or by testers.
• Integration testing : Testing of combined parts of an application to determine if they function together correctly. It can be any type of application which has several independent sub applications, modules.
• Functional testing : Black box type testing to test the functional requirements of an application. Typically done by software testers but software programmers should also check if their code works before releasing it.
• System testing : Black box type testing that is based on overall requirements specifications. Covers all combined parts of a system.
• End to End testing : It's similar to system testing. Involves testing of a complete application environment similar to real world use. May require interacting with a database, using network communications, or interacting with other hardware, applications, or systems.
• Sanity testing or smoke testing : An initial testing effort to determine if a new sw version is performing well enough to start for a major software testing. For example, if the new software is crashing frequently or corrupting databases then it is not a good idea to start testing before all these problems are solved first.
• Regression testing : Re-testing after software is updated to fix some problems. The challenge might be to determine what needs to be tested, and all the interactions of the functions, especially near the end of the sofware cycle. Automated testing can be useful for this type of testing.
• Acceptance testing : This is the final testing done based on the agrements with the customer.
• Load / stress / performance testing : Testing an application under heavy loads. Such as simulating a very heavy traffic condition in a voice or data network, or a web site to determine at what point the system start causing problems or fails.
• Usability testing : Testing to determine how user friendly the application is. It depends on the end user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
• Install / Uninstall testing : Testing of full, partial, or upgrade install / uninstall processes.
• Recovery / failover testing : Testing to determine how well a system recovers from crashes, failures, or other major problems.
• Security testing : Testing to determine how well the system protects itself against unauthorized internal or external access and intentional damage. May require sophisticated testing techniques.
• Compatability testing : Testing how well software performs in different environments. Particular hardware, software, operating system, network environment etc. Like testing a web site in different browsers and browser versions.
• Exploratory testing : Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
• Ad-hoc testing : Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
• Context driven testing : Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life critical medical equipment software would be completely different than that for a low cost computer game.
• Comparison testing : Comparing software weaknesses and strengths to competing products.
• Alpha testing : Testing of an application when development is nearing completion. Minor design changes may still be made as a result of such testing. Typically done by end users or others, not by programmers or testers.
• Beta testing : Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end users or others, not by programmers or testers.
• Mutation testing : A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (defects) and retesting with the original test data/cases to determine if the defects are detected. Proper implementation requires large computational resources.
Wednesday, June 16, 2010
Search Engine Optimization
1.Create unique, accurate page titles
Accurately describe the page's content
Create unique title tags for each page
Use brief, but descriptive titles
2.Make use of the "description" meta tag
Adding description meta tags to each of your pages is always a good practice in case Google cannot find a good selection of text to use in the snippet.
Accurately summarize the page's content
Use unique descriptions for each page
3.Improve the structure of your URLs
Use words in URLs
Create a simple directory structure
Provide one version of a URL to reach a document
4.Make your site easier to navigate
Create a naturally flowing hierarchy
Use mostly text for navigation
Use "breadcrumb" navigation - A breadcrumb is a row of internal links at the top or bottom of the page that allows visitors to quickly navigate back to a previous section or the root page.
Put an HTML sitemap page on your site, and use an XML Sitemap file
Consider what happens when a user removes part of your URL
Have a useful 404 page
5.Offer quality content and services
Write easy-to-read text
Stay organized around the topic
Use relevant language
Create fresh, unique content
Offer exclusive content or services
Create content primarily for your users, not search engines
6.Write better anchor text
Choose descriptive text
Write concise text
Format links so they're easy to spot
Think about anchor text for internal links too
7.Use heading tags appropriately
Imagine you're writing an outline
Use headings sparingly across the page
8.Optimize your use of images
Use brief, but descriptive filenames and alt text
Supply alt text when using images as links
Store images in a directory of their own
Use commonly supported filetypes
9.Make effective use of robots.txt
Use more secure methods for sensitive content
10.Be aware of rel="nofollow" for links
If you link to a site that you don't trust and don't want to pass your site's reputation to, use nofollow
Lastly, if you're interested in nofollowing all of the links on a page, you can use "nofollow" in your
robots meta tag, which is placed inside the tag of that page's HTML.This method is written as
11.Promote your website in the right ways
Blog about new content or services
Don't forget about offline promotion
Know about social media sites
Add your business to Google's Local Business Center
Reach out to those in your site's related community
12.Take advantage of web analytics services
Get insight into how users reach and behave on your site
Discover the most popular content on your site
Measure the impact of optimizations you make to your site
Accurately describe the page's content
Create unique title tags for each page
Use brief, but descriptive titles
2.Make use of the "description" meta tag
Adding description meta tags to each of your pages is always a good practice in case Google cannot find a good selection of text to use in the snippet.
Accurately summarize the page's content
Use unique descriptions for each page
3.Improve the structure of your URLs
Use words in URLs
Create a simple directory structure
Provide one version of a URL to reach a document
4.Make your site easier to navigate
Create a naturally flowing hierarchy
Use mostly text for navigation
Use "breadcrumb" navigation - A breadcrumb is a row of internal links at the top or bottom of the page that allows visitors to quickly navigate back to a previous section or the root page.
Put an HTML sitemap page on your site, and use an XML Sitemap file
Consider what happens when a user removes part of your URL
Have a useful 404 page
5.Offer quality content and services
Write easy-to-read text
Stay organized around the topic
Use relevant language
Create fresh, unique content
Offer exclusive content or services
Create content primarily for your users, not search engines
6.Write better anchor text
Choose descriptive text
Write concise text
Format links so they're easy to spot
Think about anchor text for internal links too
7.Use heading tags appropriately
Imagine you're writing an outline
Use headings sparingly across the page
8.Optimize your use of images
Use brief, but descriptive filenames and alt text
Supply alt text when using images as links
Store images in a directory of their own
Use commonly supported filetypes
9.Make effective use of robots.txt
Use more secure methods for sensitive content
10.Be aware of rel="nofollow" for links
If you link to a site that you don't trust and don't want to pass your site's reputation to, use nofollow
Lastly, if you're interested in nofollowing all of the links on a page, you can use "nofollow" in your
robots meta tag, which is placed inside the tag of that page's HTML.This method is written as
11.Promote your website in the right ways
Blog about new content or services
Don't forget about offline promotion
Know about social media sites
Add your business to Google's Local Business Center
Reach out to those in your site's related community
12.Take advantage of web analytics services
Get insight into how users reach and behave on your site
Discover the most popular content on your site
Measure the impact of optimizations you make to your site
Wednesday, June 2, 2010
HP-shutdown
unix command prompt
w
shutdown -h -0
after confirmation goto backup(lower part of the machine) menu
by pressing + successively there will be a option named:shutdown.Press it
after that off the backup switch
after that off the cpu switch
reboot -h
VECTOR- EDPRC problem
Problem:
When edprc was running , it didn't complete accurately as Transaction Log was full.
Solution:
1.First of all clear Transaction Log with the following command:
dump trunc veclive with truncate_only
2.Change the batch to be run with the following command:
Show scpUpd BAT E
3.Insert into SESSION_CUR Table the value for edprc.
insert into SESSION_CUR value (7)
4. delete from SESSION_DLY
5.Then run edprc
Sunday, March 7, 2010
Disaster Recovery- Some basic issue
Disaster Recovery Plan
A disaster recovery plan can be structured in many different ways and can contain many types of information, including:
- A plan to acquire hardware.
- A communication plan.
- A list of people to be contacted in the event of a disaster.
- Instructions for contacting the people involved in the response to the disaster.
- Information on who owns the administration of the plan.
Preparing for a Disaster
To prepare for disaster, it is recommended that you periodically perform the following steps:
- Perform regular database and transaction log backups to minimize the amount of lost data. It is recommended that both system and user databases be backed up.
- Maintain system logs in a secure fashion. Keep records of all service packs installed on Microsoft® Windows NT® 4.0 or Windows® 2000 and Microsoft SQL Server™. Keep records of network libraries used, the security mode, and the sa password.
- Maintain a base functionality script for quickly assessing minimal capability.
- Assess the steps you need to take to recover from a disaster ahead of time on another server, and amend the steps as necessary to suit your environment.
Thursday, March 4, 2010
WEB Content Management System,CMS
A CMS facilitates editing and updating site content as often as you wish without skills in HTML programming or assistance from an IT department.
Wednesday, January 13, 2010
War Between Business and IT
Susan Cramm's forthcoming book, 8 Things We Hate About IT: How to Move Beyond the Frustrations to Form a New Partnership With IT (Harvard Business Press, March 2010), examines the frustrations common to the business-IT relationship. "Nobody hates the people in IT, but everybody - business and IT leaders alike- hates the current IT system," says Cramm, founder and president of the IT leadership firm Valuedance.
Her list of eight hates was validated by a 2009 survey of business and IT leaders. It's built around issues facing organizations, and includes perspectives from both sides.
Line leaders hate when IT is overly bureaucratic and control oriented.
IT leaders hate when the business makes half-baked requests and is clueless about impact.
Line leaders hate when IT consists of condescending techies who don't listen.
IT leaders hate when the business treats IT professionals like untrustworthy servant-genies.
Line leaders hate when IT is reactive rather than proactive.
IT leaders hate when the business develops plans without including IT.
Line leaders hate when IT proposes "deluxe" when "good enough" will do.
IT leaders hate when the business focuses on costs and not value.
Line leaders hate when IT doesn't deliver on time.
IT leaders hate when the business changes its mind all the time.
Line leaders hate when IT doesn't understand the true needs of the business.
IT leaders hate when the business wants it all - right now - regardless of ROI.
Line leaders hate when IT doesn't support innovation.
IT leaders hate when the business isn't IT-smart and doesn't use or understand IT systems.
Line leaders hate when IT inhibits business change.
IT leaders hate when the business is never satisfied with IT.
Tuesday, January 12, 2010
Important BOOKS,2010
8 Things We Hate About IT
By Susan Cramm
Harvard Business Press
Available
The leadership coach and former CIO explains how business executives and operatives should understand IT—and how the two sides can work together for mutual success.
The Practical CIO: A Common-Sense Guide for Successful IT Leadership
By Jose Carlos Eiras
Wiley
Available
The former international CIO outlines the new reality for IT leaders, with anecdotes and perspectives from a number of IT leaders.
Analytics at Work: Smarter Decisions, Better Results
By Thomas Davenport, Jeanne Harris and Robert Morison.
Harvard Business Press
Available
The follow-up to Competing on Analytics offers a step-by-step framework for companies to use analytics to make better decisions.
Denial: Why Business Leaders Fail to Look Facts in the Face
By Richard S. Tedlow
Portfolio Hardcover
Available March 4, 2010
The Harvard Business School professor looks at why some companies ignore challenges and problems, while others succeed by meeting them head-on.
Switch: How to Change When Change is Hard
By Chip and Dan Heath
Broadway
Available
The sibling academics, who co-wrote Made to Stick, return with a guide for understanding why the human brain resists change, with examples of how to turn those challenges on their heads.
Lords of Strategy: The Secret Intellectual History of the New Corporate World
By Walter Kiechel
Harvard Business Press
Available
How three consulting leaders and an academic brought corporate strategy to the forefront—and changed business as we know it.
Mojo: How to Get It, How to Keep It, How to Get It Back if You Lose It
By Marshall Goldsmith
Hyperion
Available Feb. 2, 2010
The renowned executive coach explains how leaders can harness their identity, achievement and reputation to reach the full potential.
The Right Fight: How Great Leaders Use Healthy Conflict to Drive Performance, Innovation, and Value
By Saj-nicole Joni and Damon Beyer
HarperBusiness
Available
The founder of Cambridge International teams with a Booz & Company consultant to explain how corporate leaders can channel conflict to get better results.
Seizing the White Space: Business Model Innovation for Growth and Renewal
By Mark Johnson
Harvard Business Press
Available
A primer on the art of business model innovation, from the chairman of Innosight, which was co-founded by
The Death of Modern Management: How to Lead in the New World Disorder
By Jo Owen
Wiley
Available Feb. 1, 2010
A how-to guide for rewriting the rules of management following the global economic collapse, by the author and consultant.
Reorganize for Resilience: Putting Customers at the Center of Your Business
By Ranjay Gulati
Harvard Business Press
Available Jan. 9, 2010
The Harvard Business School professor uses a decade of research to reveal five key elements that successful companies employ to build effective customer strategies.
Hyperformance: Using Competitive Intelligence for Better Strategy and Execution
By T.J. Waters
Jossey-Bass
Available
The intelligence expert and former business executive outlines a strategy for understanding the competition and staying ahead of the pack.
Beating the Commodity Trap: How to Maximize Your Competitive Position and Increase Your Pricing Power
By Richard D'Aveni
Harvard Business Press
Available
The Dartmouth professor and consultant argues that any company can become commoditized—and offers ways to avoid falling into that trap.
How the Best Leaders Lead
By Brian Tracy
AMACOM
Available
The author and consultant chronicles the leadership secrets of business executives from 1,000 companies in 52 countries.
The China Strategy: Harnessing the Power of the World's Fastest-Growing Economy
By Edward Tse
Basic Books
Available March 23, 2010
Booz & Company’s China chief explains the four drivers for changing the way companies do business in the world’s economic juggernaut.
Monday, December 7, 2009
VECTOR MQT problem
Problem:
There are values in MATCH_Q_TRAN table but there is no value in BUSY_SCRIPS_TRAN table.
Solution:
Update MatchCopyNo in MATCH_Q_TRAN table for that scrip with the value = 0
Symptom:
There were two values in MATCH_Q_TRAN which were not in BUSY_SCRIP table.
These values were not executing.
Occured after deletion of 57 scrips.It didn't come in MOCK session but occured in live on next day.
Solution:
MatchCopyNo is updated to 9 and ran 9th copy of HMserver manually.
==============================================================================================
1> select * from MATCH_Q_TRAN;
RecId ScripId XactId XactType TradingMode BSFlag
DtTime BPrice BTotalQty
BReplenishQty BPendQty SPrice STotalQty
SReplenishQty SPendQty BrokerCd TraderCd ClientCd OrderDuration
TillDtTime MatchCopyNo LastBTradeId LastSTradeId
TradeSessNo ReferenceCd ShortSellFlag
-------------------- ----------- ----------- -------- ----------- ------
-------------------------- ------------------------ -----------
------------- ----------- ------------------------ -----------
------------- ----------- -------- -------- -------- -------------
-------------------------- ----------- ------------ ------------
----------- -------------- -------------
25888.000000 23004 15960 D H S
Dec 8 2009 1:14PM 0.00 0
0 0 4,320,000.00 200
100 100 SES CTG01 CTG421 GFD
Jan 1 1900 12:00AM 2 0 0
1 NULL N
26798.000000 32009 21378 L H S
Dec 8 2009 1:20PM 0.00 0
0 0 3,722,000.00 500
0 500 SHLCT DHK01 875 GFD
Dec 8 2009 1:20PM 1 0 0
1 NULL N
Subscribe to:
Posts
(
Atom
)