Posted by Support TIC on Tue, May 15, 2012 @ 08:55 AM
Have you ever considered modeling?
No, we’re not suggesting you strut down the fashion runway or try to get that little ship to fit inside the bottle. We are talking about modeling software-intensive systems using Unified Modeling Language (UML2).
Before we talk about modeling software, let’s look at a more familiar kind of model, a blueprint for a home. A home is a complex set of elements like rooms, stairways, entranceways, windows, electrical services, and plumbing that must work together to form a useful, safe, and enjoyable living environment.
Over time, the architecture profession has evolved a set of standard drawing types that capture the organization, placement, and interaction of these building block elements. Three examples of blueprint drawings show an external view, floor plan, and electrical services of a home.
Long ago, it took years of drafting apprenticeship to create such plans. Today, it still takes training and skill to do the architecture, but architects use powerful computer-aided design (CAD) tools to render these plans and make them useful. In fact, if you purchase a factory-built home, the design models used to generate these drawings also drive the automated production process of the home.
Modeling business applications using UML2 is much the same as the modern building architecture process. As an IT architect, you still must know how users will interact with your system, and how available and reliable it must be. The architect must estimate the system’s transaction capacity, screens, controllers, data entities needed, and service behavior.
However, this is little different than the home's architect knowing know how the home buyer will use the home (e.g. daily living, weekend cabin, summer shore), the home's expected living capacity (e.g. number of bedrooms and bathrooms, size of kitchen, finished basement, separate apartment), and its necessary electrical, heating, cooling, and plumbing capacities.
To create business application systems UML2 models let you express meaning about the structure and behavior of software by drawing diagrams. If you construct the right models in the right way, and have the right Model-Driven Architecture (MDA) tools, you can turn your models directly into executable code. This is no different from a CAD model driving the production process of a factory-built home. To learn more about MDA, see our blog post on Model-Driven Architecture.
Which are the right models?
The right models are Clear and transparent. The models that are understandable to business stakeholders and technologists are usually Platform-Independent Models (PIM). The PIM exactly captures the user interaction, behavior, and structure of your software solution without all the technical details that obscure business meaning. Remember that the architecture drawings of your home had to be clear and transparent, or the builders would have had real problems creating the structures and services.
Tthe PIM is not just a great communication tool. The PIM has First Class IT Asset Value. Remember that with the right MDA tool support, you can transform your PIM directly into executable software. We do exactly that with our BluAge MDA tool suite (www.bluage.com). We transform PIMs directly into your desired target technologies, like Java or .Net. This means your PIM is a first class IT asset that has value and life beyond any particular technical implementation. It becomes the “Single Source of Truth” for your software. Homeowners who have home renovation done without the benefit of a set of architectural drawings learn quickly that renovation turns from engineering into guessing and hoping.
Beyond communication and IT Assets, the PIM is about process efficiency and effectiveness. Drawing models is much faster than writing system design documents, and so is reading the model diagrams. Transforming models directly into code is much faster and more reliable than error-prone hand coding. This is especially true if you have not yet established mastery of the target technology platform. Whether the domain is home building or application software, when the power of modeling and automated production is applied, the result is high-quality output, built on time and in budget.
When our BluAge tool suite transforms models, it is using the latest frameworks and techniques appropriate to the target architecture you select. The faster your PIM turns into code, the faster it can be tested and approved, or scheduled for PIM review and enhancement.
So, we’ve given you three good reasons to do some modeling.
- Clarity and Transparency - Your business stakeholders will understand your software design intentions much more easily and thoroughly, when compared to reading requirements or trying to understand code
- Asset Value - You will have a first class IT asset that documents your software in a language-independent way, and that transcends any particular implementation technology
- Efficiency and Effectiveness – Authoring models is faster than writing functional and technical specifications, and reading and checking models is faster than reading weighty documents. Transforming models into code is much faster than hand coding and rapid transition to testing means efficient and effective approval, or feedback.
NonStop, MDA, and Modeling
TIC Software (http://www.ticsoftware.com), using the MDA tool suite from our business partner BluAge (www.bluage.com) , and focused modeling techniques tailored to BluAge, is helping customers build NonStop Java applications quickly. Sorry, but we don’t build houses.
Here are some modeling specifics, at a glance.
- BluAge only requires three of more than one dozen UML2 diagram types.
- Each diagram type delivers a specific view of your system’s structure and behavior.
- The rich set of UML2 Stereotypes and Tags helps you clarify your model’s meaning.
- A set of intuitive “Modeling Wizards” multiplies your modeling efficiency
- BluAge’s model checker quickly finds model “syntax” errors, when you don’t use wizards.
Instead of building every conceivable UML2 diagram, confusing your stakeholders, and wasting valuable time, we speed things up by building the models that your users will understand, and that BluAge can turn directly into executable code. The generated code is tested, and approved, or the model is changed and the code regenerated, as necessary. There is no extra diagramming and no hand coding!
We said that the Platform Independent Model (PIM) avoids technical implementation details. Modelers focus on building business logic rather than dealing with technical matters like which Java frameworks to use. Today, our generated code uses popular Java frameworks like “Hibernate” and “Spring”, also recommended by HP. Of course, as the Java world marches on, BluAge will march with it, using the best technical frameworks then available.
Take Away
Our modeling approach focuses on creating the right model diagrams that will result in generating the right software solution for you.
Building the right models enables business stakeholders and technical staff to participate together, in the modeling process. Modeling focuses on business rules, calculations, and process flows, while
code generation handles “application burden” with frameworks.
Our BluAge MDA tool suite immediately generates those business models into executable solutions so business stakeholders can validate them, or make changes. The bottom line is protected by delivering value on time, and avoiding disaster.
Whether you are interested in brand-new development, or want to re-engineer your existing COBOL applications into Java, TIC, and our modeling with BluAge, will make things happen more quickly, with higher quality, and lower solution lifecycle cost.
Are you ready to learn more about TIC, MDA and NonStop? Send us an e-mail Schedule a conversation by emailing us at sales-support@ticsoftware.com.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
 |
Stuart Selip owns and operates Principal Consulting, LLC, an IT Strategy consulting firm that is a business partner of TIC Software. Prior, as the Chief Executive Officer of Luxoft’s Consulting Strategies unit, he managed delivery of IT Strategy consulting to Fortune 500/Global 2000 firms in the Financial Services, Insurance, and Media industries. Read More |
Posted by Phil Ly on Thu, May 10, 2012 @ 03:17 PM
Some people may believe in: “If it ain’t broke, don’t fix it.” Unfortunately, this saying undermines the importance of investing in strategic options with foresight to avoid pending disasters.
A couple of cases in point:
I started my first job in the 1970’s with an intelligent terminal company called Sycor , which was eventually acquired by Northern Telecomm. In those days, Sycor terminals were used for Source Data Entry (key to disk), and its programming language was called – ironically – TAL for Terminal Application Language. It was an Assembler/Macro like language, which required one to work with registers, memory addresses and screen fields. When Sycor introduced the Sycor 440 machine in 1976, it had a whopping 64K of memory, a 10 MB hard disk, and a COBOL compiler. Surprisingly, I was one of the very few field personnel that knew COBOL at the time. When I asked some of the more senior Sycor analysts about COBOL, their response was: “Why would we need COBOL? Assembler language is faster and uses less memory!” Well, we all know that the world has moved past Sycor TAL and assembler programming languages.
Fast forward to 2001: I was giving a Web Enabling workshop to a NonStop customer in Chicago, when one of the senior COBOL programmers raised his hand and asked: “
COBOL works perfectly well for us. Why would we want do any of this web stuff?” That company was later acquired and sadly, they no longer use NonStop. None of the NonStop developers was asked to stay to work in the new IT environment, which was Unix, Java and totally web-based.
Today, the NonStop has a lot of modern technologies available, including support for SQL, web server, Java, Eclipse, SOAP and others. Yet, a lot of users still haven’t taken advantage of some or all of these new technologies. In many cases, they are still developing COBOL applications that use 6530 terminals, Enscribe files and interface with other platforms using FTP. Seriously, it is in your best interest to start considering options to modernize your NonStop environment.
“Why should I be interested in modernizing?”
- Prevent self-obsolescence
Working with new technologies will expand your current and future employment opportunities.
- It could make your job easier
There are a lot of facilities, tools and utilities available in Java, Apache, SOAP, and other new technologies that are “off-the-shelf” which you can leverage without any coding
- Build a stronger and more dynamic team
If you are a manager, adapting new technology will create positive challenges for your current team, and make it easier to hire new staff.
“What should I do?”
- Make time
I know that all of us are very busy at work, barely keeping our head above water. I encourage you to check out this blog “Create Time to Change Your Life.”
- Pick one topic to start
Any topic: Java, Web Service, Apache, etc. Instead of trying to learn everything about all the modern tools, pick just one thing to start learning. Start slowly but work on it consistently. If you are looking for a recommendation, I would suggest Java. Why? Because it is easy to set up and learn on your desktop, and you can test your programs on the NonStop very easily. In my next blog, I will cover more on Java and NonStop, and the benefits that it offers.
- Look for free tutorials
There are many excellent tutorial blogs and YouTube videos available. Here are some examples:
Also, visit our blog (http://blog.ticsoftware.com) for an upcoming series of Modernization Tutorial blogs and vides.
Don’t Wait. Start today.
In the history of IT, complacency and shortsightedness usually lead to obsolescence in applications, platforms and people. It may not be “broke” right now, but you can’t afford to wait for it to be broken before you try to fix it. By then, it will be too late.
Need professional service help?
Contact TIC Software.
If you need help to get started, you can benefit from our Workshops or Quick Start Service. TIC Software is ready to help you modernize your NonStop applications and develop new software solutions. Check out our Modernization Service suite on our web site.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
 |
Phil Ly is the president and founder of TIC Software, a New York-based company specializing in software and services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Prior to founding TIC in 1983, Read More |
| |
|
Posted by Support TIC on Fri, Apr 20, 2012 @ 03:38 PM
Want to minimize development risks? Adopt the right methodology!
In this column, I would like to discuss how the right methodology can minimize risks and accelerate the development process.
Development Risks
Steve McConnell, author of the classic book on development “Rapid Development: Taming Wild Software Schedules” attributes insufficient risk management as one of “classic mistakes” in development projects. He wrote:
“…Failure to manage risks is one of the most common classic mistakes.” And “… if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one..”
A software development methodology that fits your project can reduce your risk of software delivery failure. So, which risks need reducing?
- Implementation Risks – You deliver late, over budget, missing features, with low quality
- Impact Risks – The many benefits of modernization you promised have failed to materialize
- Strategic Risks– It’s tomorrow in the marketplace but you’re modernizing yesterday’s solution
If you have been programming on a legacy system, then chances are you already know of or are using a classic methodology – the “Waterfall” methodology.
Waterfall
This methodology has been around for more than half a century and remains popular. Waterfall processes begin with gathering requirements, and continue with requirements analysis, solution design, software development, and finally solution testing, before delivery to stakeholders.
Waterfall can deliver good results in software delivery when four key conditions are met:
- All requirements must be known before software development begins
- All stakeholders must agree on all requirements
- All requirements must remain unchanged during the delivery and adoption cycle
- The underlying solution architecture must already exist, and be well understood
When familiar stakeholders request small projects that make incremental changes to an existing software solution, the requirements of Waterfall are met. In other words, Waterfall properly supports the familiar work of legacy solution maintenance, like adding to, or modifying existing screens, reports, or calculations.
Modernizing NonStop applications or building new solutions in a new technology mix will put all of these conditions into question. Say you want to follow HP’s advice to NonStop users modernizing NonStop applications by using modern tools, object-oriented programming models, and technologies. Such a modernization initiative should be based on a modern model.
Waterfall is not a modern programming model! A modern programming model focuses on delivering software quickly, so stakeholders can judge whether it is correct and useful. Getting rapid feedback means learning and improving early in the modernization effort, rather than discovering a huge compound failure at the project’s end. Testing happens at the end of the Waterfall process. By then it is too late to avoid catastrophe.
New technologies are different than your current underlying solution architecture. For Example, Java is an object-oriented language and COBOL is not. The entire approach to problem analysis and solution design is different. Data flow diagrams and functional decomposition are not going to help you uncover the right classes and assign attributes and operations to them. Concepts like classes and operations don’t even exist in COBOL, and Waterfall won’t help you with this dilemma.
Here is the Good news – TIC Software can help you! Now you can benefit from rapid application development with modern tools, programming models and technologies. We make this possible with Model-Driven Architecture (MDA) and a methodology that gives great results.
NonStop, MDA, and Methodology
TIC Software (http://www.ticsoftware.com), using the MDA tool suite from our business partner BluAge (www.bluage.com) , and a pragmatic development methodology tailored to MDA, is helping customers build NonStop Java applications quickly.
Here is our methodology, at a glance.
- We take an iterative approach to software development, focusing on exposing and eliminating software delivery risk.
- Working with you and your team, we identify critical core application functionality early in the development cycle.
- We build standards-based UML models to reflect the core functionality, generate code, and deliver solutions that your stakeholders can review quickly
- Changes can be incorporated into the model, which is then regenerated instantly
- Instead of trying to document every single requirement, providing a complete requirements analysis, and committing to a full design specification before a single line of code has been written, we short-circuit the whole process.
This approach quickly converges on the right result. At the end of the iteration, we collectively review and learn from our recent experience. Each subsequent iteration benefits from that cumulative learning.
The code we generate leverages popular Java frameworks like “Hibernate” and “Spring”, which are some of the tools recommended by HP. This means we are free to focus on building business logic and solving business problems for you, rather than wrestling with technical “application burden” issues like middle-tier object management and data persistence. You gain access to popular but complex frameworks so they deliver results instead of creating delay and frustration. As the Java world evolves and new frameworks and techniques appear, the BluAge MDA tool will evolve in parallel, making the “new” accessible and available with no disruption.
Take Away
Our Iterative software development approach with MDA exposes software delivery risks early, avoiding project catastrophes. Building graphical models of software enables business stakeholders and technical staff to participate, together, in modeling. Modeling focuses on business rules, calculations, and process flows, while code generation handles “application burden” with frameworks. MDA immediately generates those business models into executable solutions so business stakeholders can validate them, or make changes. The bottom line is protected by delivering value on time, and avoiding disaster.
Whether you are interested in brand-new development, or want to re-engineer your existing COBOL applications into Java, TIC and MDA will make things happen more quickly, with higher quality, and lower solution lifecycle cost.
Are you ready to learn more about TIC, MDA and NonStop? Schedule a conversation by emailing us at sales-support@ticsoftware.com.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
|
Stuart Selip owns and operates Principal Consulting, LLC, an IT Strategy consulting firm that is a business partner of TIC Software. Prior, as the Chief Executive Officer of Luxoft’s Consulting Strategies unit, he managed delivery of IT Strategy consulting to Fortune 500/Global 2000 firms in the Financial Services, Insurance, and Media industries. Read More |
Posted by Support TIC on Thu, Apr 12, 2012 @ 04:00 PM
Who cares about standards? YOU should!
Why?
Standardized products and services are valuable because they:
- Provide consistent quality
- Minimize learning curve
- Support compatibility
- Promote Portability
Rather than asking why we need standards, we might usefully ask ourselves what the world would be like without standards. What would it be like to have to relearn how to operate a new car, a new phone or a new computer every time? Not very productive, for sure!
Likewise, one can reap benefits from IT standards in software engineering technologies. Like the Model-Driven Architecture (MDA), for example. MDA proposed by the Object Management Group (OMG) defines an approach to information systems specification that separates the specification from the implementation.
In this article, I will describe a success story of how a standards-based Model Driven Architecture (MDA) approach to building software allows a large, complex software system to be delivered in a tight time frame, with high quality.
It is a project that took place in 2005 and 2006, in the state of Ohio. The Statewide Automated Child Welfare Information System (SACWIS) project had an aggressive delivery completion time line of 18 months. The selected System Integration (SI) vendor opted to use a MDA tool to facilitate the development process.
The system was delivered in Java, while many of the development team members had little or no previous experience with that language, its supporting technologies, or the iterative software development lifecycle approach used to drive the project.
The results were:
- The MDA tool multiplied the productivity of the developers making 10 day delivery iterations possible by generating all of the “drudge” code while developers focused on delivering “exciting” stuff like business rules and process flows
- Users and stakeholders gained confidence in the 10 day process, and gave rapid feedback to developers, avoiding late-term “surprises”
- Despite a project-long 56% delivery team turnover, the architectural rigor of the MDA tool, and the high-quality UML models meant the project delivered on time, and with “right” scope
NonStop and MDA
Good news! Now you can benefit from rapid application development for NonStop using MDA!
TIC Software (www.ticsoftware.com), using the MDA tool suite from our business partner BluAge (www.bluage.com) , is helping customers build NonStop Java applications quickly.
Our UML models are used to generate code that leverages popular Java frameworks like “Hibernate” and “Spring”. This means we are free to focus on building business logic and solving business problems for you, rather than wrestling with technical “application burden” issues like middle-tier object management and data persistence. You gain access to popular but complex frameworks so they deliver results instead of creating delay and frustration. As the Java world evolves and new frameworks and techniques appear, the BluAge MDA tool will evolve in parallel, making the “new” accessible and available with no disruption.
What’s the take-away?
MDA, Agile, and Iterative software development are all standards-based, and in the hands of a committed team, provided a synergism that delivered complex mission-critical software for the State of Ohio on time, and with high quality.
Whether you are interested in brand-new development, or want to re-engineer your existing COBOL applications into Java, TIC and MDA will make things happen more quickly, with higher quality, and lower solution lifecycle cost.
Are you ready to learn more about TIC, MDA and NonStop? Schedule a conversation by emailing us at sales-support@ticsoftware.com.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
|
Stuart Selip owns and operates Principal Consulting, LLC, an IT Strategy consulting firm that is a business partner of TIC Software. Prior, as the Chief Executive Officer of Luxoft’s Consulting Strategies unit, he managed delivery of IT Strategy consulting to Fortune 500/Global 2000 firms in the Financial Services, Insurance, and Media industries. Read More |
Posted by Support TIC on Fri, Mar 30, 2012 @ 02:45 PM
MDA Intro
Guess what? You have legacy applications. What are they? Well, they are COBOL applications that are many years old. Our loyal developer community is looking forward to retirement, so who will attend to the care and feeding of these “classic” applications? By the way, COBOL isn’t the only legacy technology You’re right if you think PACBASE, “C” and “C++” applications or fat-client solutions like those constructed in the 1990s using PowerBuilder, Delphi, and Gupta SQLWindows are legacy applications today. These are all “legacy”, but the greatest volume of “good old code” was written in COBOL.
What is in your legacy applications? Usually they contain a mix of business rules, process flows, screen interactions, batch processes, and reporting that, through years of maintenance and enhancement, have grown in size, scope, and complexity. Some of those applications could be called “High Value”, while others are not unique or critical.
Is this good news? Well, yes and no. High-value legacy code might just form the competitive basis for your company. The intellectual property (IP) in legacy applications often competitively differentiates your organization from its peers, and you are subject matter experts (SME) of those applications. On the other hand, newly-minted IT professionals no longer study COBOL. Instead, they think more about Objects, Java, C#, and web technologies. We have a good approach to this situation of legacy code and new coders. We think your high-value code could benefit from some intensive reverse engineering that extracts the intellectual value of the software, and gives it a new lease on life. Finding the value in legacy applications has been a “holy grail” quest for more than 20 years, but only recently has modernization moved from alchemy to engineering. How has this happened? Think Model-Driven Architecture (MDA).
What is MDA? Simply, it is a graphical modeling approach to object-oriented software development, specifying both the static technology building blocks (the classes, information content, and operations) and dynamic behavior (“when the online customer clicks on “place order” the system will….”) of a software solution as elements of a model. Using MDA, you, as SMEs, help capture the IP of your legacy applications, without retaining the code in which it was written. Think of using MDA as applying an organized process to build a set of really powerful “flow charts” using Unified Modeling Language (UML). UML wasn’t around when your applications were written, but today it is an industry-standard way of describing systems and programs, covering perspectives from overall system architecture, through internal program design. More than just pictures and charts, with the right companion technology MDA allows you to “generate” modern code, without having to sit there and write it up by hand.
No, we did not invent MDA. MDA has grown from a standards-making process of the Object Management Group (www.omg.org) in the early 2000s to something practical and useful today. Now, when you have a UML model ready to go, you can fire up an MDA application generator to read the model, and create modern code for your chosen target technology stack. Frequently, technology stack choices are Java, or Microsoft platforms, and in an MDA approach, the usual software coding process has been replaced by code generation. The trick is, you have to build your models right, and select the right generator technology. With your expertise in your existing applications and TIC’s investment in training and technology, the time is right for MDA modernization.
How do you decide which legacy applications should be modernized? It takes a rationalized IT portfolio to pinpoint your high-value applications for MDA modernization and lower-value candidates for alternative conversion, or replacement. If you’re not sure about your IT Portfolio, we can help your organization create one. Basically, you need to know about the value the legacy app delivers, vs. the cost to maintain and/or modernize it. For example, though perhaps convenient and familiar to your users, many software solutions (e.g. accounting, payroll) are not business game-changers that lead your organization to market preeminence. “Commodity” applications may not be worth modernization. Other approaches, like replacement with commercially available “off the shelf” solutions for in-house or “Cloud” access might make more sense. When you want to know more about legacy modernization, MDA, IT Portfolio Management, or any other forward-looking practice… we are ready and able to have that conversation, and deliver on what follows.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
|
Stuart Selip owns and operates Principal Consulting, LLC, an IT Strategy consulting firm that is a business partner of TIC Software. Prior, as the Chief Executive Officer of Luxoft’s Consulting Strategies unit, he managed delivery of IT Strategy consulting to Fortune 500/Global 2000 firms in the Financial Services, Insurance, and Media industries. Read More |
Posted by Phil Ly on Wed, Nov 30, 2011 @ 12:25 PM
In this article, I want to share with you some basic information on some important iTP Web Server logs. Since a lot of information is already available in the HP documentation, I thought I would give you a "Cliff Notes " tour by using "5 W's + 1 H" approach:
What?
| access.log |
The access log file records the request history of a server. The information in this file is structured in the common log format (CLF). |
| httpd.log |
The extended log file combines the functions of the access log and the error log files, recording information concerning requests and errors. This format places errors in context with the relevant request |
| error.log |
The error log file records all request and server errors. The information in this file is
structured in the common log format (CLF). |
Why?
By monitoring these logs, it allow you to gauge the health of the webserver and to detect errors as soon as they occur.
-
Are Web requests coming in?
-
Are they completing with code 200 (normal) or errors like 404 or 500?
-
What pages are being accessed?
-
Where are the requests coming in from?
-
Are there any errors?
Where?
The locations of these log files are specified by the ErrorLog directive in the server
configuration file. These are their common locations
| access.log |
/usr/tandem/webserver/logs/access.log |
| httpd.log |
/usr/tandem/webserver/logs/httpd.log |
| error.log |
/usr/tandem/webserver/logs/error.log |
Who?
The Operation team are usually the people that monitor these log files as it allows them to gauge the health of the system. If there are errors, then Development may be contacted to look at them.
| access.log |
Operation, Administrator |
| httpd.log |
Administrator, Development |
| error.log |
Administrator, Development |
How?
If you do it manually, then you should remember cat, tail and vi. For example:
- To view the whole log file (equivalent to FUP COPY)
cat access.log
- To view the last entries:
tail access.log
- You can also view them using the vi editor
vi access.log
The Take-Away 
iTP Web Server records its web activities in log files. By monitoring these log files, you can be assured that transactions are flowing normally, or if there is an error condition that needs to be addressed.
Automate! 
Instead of having to manually view these files in OSS directly, you can automate by using TIC LogWatch to:
-
Monitor the files for new entries
-
Clone a copy of the entries to a Guardian file
-
Scan the entry content to look for specific information, e.g. any HTTP completion code that is other than "200"
-
Raise an alert by sending an email to an Administrator or Developer based on the detected condition
Click here to learn more about how LogWatch can help you monitor iTP Web Server logs.
Next Topic: Know your OSS logs - Java Servlet and NS/JSP
Many iTP Web Serve applications are actually built on Java Servlet and Java Server Pages. This environment involves additional log files beyond the ones discussed here. I will discuss the usage of these log files in my next blog.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
|
Phil Ly is the president and founder of TIC Software, a New York-based company specializing in software and services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Prior to founding TIC in 1983, Phil worked for Tandem Computer in technical support and software development. |
| |
|
Posted by Phil Ly on Thu, Nov 10, 2011 @ 03:43 PM
I have always said that you can tell who the Nonstop Users are in the audience by the questions they ask, such as:
-
Is this scalable?
-
What is the performance?
-
How do I monitor it?
The last question highlights the importance that NonStop system managers place on providing responsive support for their end users. That's why system performance monitoring tools like Prognosis, MOMI and others are very popular at Nonstop installations. On the other hand, monitoring logs on the NonStop doesn't get a lot of attention beyond the use of EMS or VHS.
Yet it is an important topic that is worth a closer look. How would you answer the questions below?
When do you look at your logs? 
"When there is a problem" seems to be a common response. Surprised? Not really. Given how overloaded everyone is, there is very little time to monitor logs. Unfortunately, "When there is a problem" usually translates to "User calls up and reports a problem." Through routine monitoring of logs, problems can be detected and fixed before they affect the users.
Do you know where your logs are? 
"Well... not all of them."
When I speak of logs, most users think of system logs like VHS and EMS logs. Think again. Realistically, on a typical system, there are many other logs, such as:
-
Application logs - entries written out by COBOL, TAL, C, C++ and other applications.
-
OSS logs - Are your running iTP Web server, Java, NonStop SOAP, etc? There are lots of good information in the OSS logs.
-
Subsystem logs - Some subsystems have their own logs.
-
3rd-party application logs - If you are running a 3rd-party application, e.g. Websphere MQ, chances are it has its own logs
So if you don't know where your logs are, trying to hunt them down to resolve a problem can be time-consuming and detrimental to your service level agreement (SLA) with your end-users.
Are you overloading your logs? 
Some users try to alleviate this problem by routing EVERYTHING to EMS or VHS. Unfortunately, that creates another problem: log overload. When that happens, basically Operations staff stop looking at the hundred of log messages that fly off the screen. Yes, EMS has a very nice filtering capability that can be configured to filter out different types of messages. But the reality is that not everyone is up to the task of configuring filters, and certainly not for tens if not hundreds of different message types that flood the EMS log.
"What's in your wallet?"
I meant.. logs. If my guess is correct, chances are your logs contain more than just error messages. They probably have warnings, statistics and "stuff programmers write to log for their own use." That's another key reason a lot of people do not bother looking at logs: the content overwhelms them. See if this conversation sounds familiar:
Operator: "I just saw this message in the log. What should I do with it?"
Answer: "Oh, don't worry about it. It's a debugging statement."
Operator: "What about that one?"
Answer: "You can ignore that one, too."
The result is a misinterpretation: no need to look at log messages unless someone reports a problem.
The Take-Away
-
Monitor your logs
It can help you improve the quality of your end-user service.
-
Know your logs
Know what is in them and where they are. There's usually a lot of useful information in those logs besides error messages.
-
Have a log monitoring strategy
Take control and plan how you want to use the log information.
-
Automate as much as possible
Have a procedure in place and automate it whenever possible.
Next Topic: Know your OSS logs
As more users are starting to use OSS in one form or another, such as iTP Web Server, Java or SQL/MX, it becomes more important to pay attention to some of the logs that reside in the OSS space. In my next article, I will focus on these OSS logs.
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don't forget, you can subscribe to our blogs (top right-hand corner of this page) to get automatic email notification when a new blog is available.
|
Phil Ly is the president and founder of TIC Software, a New York-based company specializing in software and services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Prior to founding TIC in 1983, Phil worked for Tandem Computer in technical support and software development. |
| |
|
Posted by Phil Ly on Tue, Sep 06, 2011 @ 09:36 AM
Several years ago we began exploring how we might make functionality that was readily available on Windows™ platforms available to NonStop applications. We looked at porting some of them to the NonStop. We have been able to do that to a very small number of tools, like an HTTP server and email client.) Most of the other tools were either proprietary or need features that were not possible on NonStop.
We began by looking at how most applications might want to use these functions and which were the most needed. We identified PGP encryption and PDF conversion as the top two. These two functions are available on the windows platforms and are also very, very inexpensive (like free!) In most cases existing and new NonStop applications wanted to use these functions as if they were standard NonStop serverclasses.
This was the history of how TelePath came to be. We wanted to have a NonStop program, running as a serverclass, that would allow applications to simply do a Serverclass_Send or WRITEREAD sending instructions on what is to be done and, optionally include files to be processed. The reply could also point to files that returned.
Utilizing experience we had with Server Object Gateway we built two primary components. The first was a serverclass, TREMSVR, that would receive the requests and send them, via TCP/IP to a Windows server. The second, TeleRemotePC, was a Windows application that would process the request and perform whatever operation was wanted. We also wanted to provide at least some of the Tandem/NonStop fundamentals. Not only can there be multiple instances TREMSVR, but each TREMSVR process can communicate with multiple TeleRemotePC programs.
TelePath has been robustly providing a wide variety of Windows functionality for many years with a growing number of customers. Look for an upcoming Whitepaper which will provide more technical details of TelePath.
Add your feedback in the Comments area below or send us an Email at support@ticsoftware.com.
.jpg)
Donald Wickham has 31 years experience with Nonstop including 20 years for Tandem, Compaq and HP. He has been with TIC Software for 11 years in the role of Chief Architect.
Posted by Support TIC on Wed, Aug 17, 2011 @ 08:50 AM
DLLs (Dynamic Link Library) have long been used to provide optional features to programs since its inception on the Windows platform. TIC has used this capability in our Windows™ applications, TelePath and TICTransform. DLLs allow customers to extend both of these TIC products by adding their own code.
But did you know that DLL is also available on the NonStop? If fact, DLLs have been available for the NonStop platform now for a few years.
Why use DLL?
For statically linked programs, you must copy all shared libraries into your own programs; thus, complete copies of these libraries appear in all the programs that use them, and each copy consumes main memory and disk space. Also, whenever such a library is changed, it must be relinked into all the programs that need those changes.
On the other hand, if you use DLL, here are some benefits, as stated in the documentation:
- A single copy of a DLL in physical memory can be shared among multiple processes.
- A DLL that is shared among processes can appear at a different virtual address in each process and each instance has its own copy of global data that is available to its process.
- Multiple processes can use different versions of the same DLL simultaneously, though each version must have a different name or be stored in a different location in the file system.
- The same program can run simultaneously in different processes with different DLLs supplying the supporting data and functions.
- A new version of a DLL can be introduced without having to alter a program or DLL that references it.
- A running application can cause a DLL to be loaded dynamically and to make its functions and data accessible.
Explicit versus Implicit
On the Nonstop there are "explicitly linked" and "implicitly linked or programmatically loaded" DLLs. Most DLLs are explicitly linked, where the DLL is referenced when the program is being linked. Implicitly linked or programmatically loaded is just what the name implies, the DLL is loaded via a call to an API method.
Recently we have been able to utilize the implicit linking capabilities of DLLs.
XML Thunder, a third-party tool that TIC provides to the NonStop market, provides services to create and parse XML documents. XML Thunder creates source code that is compiled and bound into customer applications. Since these source code modules, called handlers, are completely self-contained, they lend themselves to being used in implicitly linked DLLs. A project was started to explore how that could be done.
It turned out to be fairly straight forward. By wrapping the XML Thunder handlers in a common function, each handler could be called on an as-needed basis. This is accomplished by doing a programmatic load of the DLL containing the appropriate handler and a call to a common function.
Our DLL Experience
We’ve discovered some things about doing this that we felt would be helpful to share.
- Have a common function that is exported (made available) in each of the DLLs. This function must have the same API or signature in all the DLLs.
- The DLLs are written in C/C++ to enable finer control of variable length structures. The returned structures from the DLL are allocated by the DLL since it alone knows how big they are, and released by the calling program.
- A word of caution: Any trap that occurs in the DLL causes the whole program to trap and abend. A try-catch block cannot prevent this.
Summary
Using DLL in your NonStop programs can provide additional flexibility in extending your code. In some ways the implicitly linked DLLs are similar to the requester-server model we are all familiar with. By having a separation of function between the requester and server, changes can be made to either without impacting the other. Implicitly linked DLLs provide a similar separation and flexibility. Modularly independent, loosely coupled design has long been a standard and implicitly linked DLLs provide that.
Got a DLL question or programming experience you want to share? Add your feedback in the Comments area below or send us an Email at support@ticsoftware.com.
Donald Wickham has 31 years experience with Nonstop including 20 years for Tandem, Compaq and HP. He has been with TIC Software for 11 years in the role of Chief Architect.
Posted by Phil Ly on Tue, Jun 07, 2011 @ 10:17 AM
If you are a SOAP/AM Server user, then you know how easy it is to create a web service using the SOAP/AM Control Panel in a matter of minutes.
SOAP/AM Server stores information about the web services in Service Definition Files (SDF) within its Virtual File System (VFS), which can be viewed easily from a web browser. Once a service is created,the SDF file can be modified by moving it to the desktop. After the needed change is made to the SDF, it can then be saved back to the VFS.
This process is pretty straightforward and can be done very quickly when you need to work on one or two SDF's occasionally. But there may be times when you need to make changes to a large number of SDF's. One common example is when you want to move (promote) the service definitions from the QA environment to the Production environment. Let's say: you have just finished testing the web services in QA, and now you need to move all the SDF's to Production. Sometimes, you may even need to change some environmental parameters, such as: the Pathmon name in Production may be different from the one in QA. What is the best way to accomplish that?
To address that need,TIC Software has developed SDFTool, to simplify several of these operations. SDFTool can be used to
- View the contents of an SDF file.
- Modify the pathmon information for a service.
- Copy a service from one SOAP/AM Server instance to another, optionally changing the pathmon information.
By using SDFTool, you can operate on a large number of SDF's very quickly.
Here is a short video to demonstrate how SDFTool works.
In summary, SDFTool facilitates your job of moving SDF's from one SOAP/AM Server environment to another. It is another nice feature that makes SOAP/AM the most user-friendly web service product on NonStop.
If you are interested in getting a copy of SDFTool, please send your request via email to support@ticsoftware.com.
Please check for new blogs on this subject (you can subscribe) and check our website for webinar announcements.
Got a suggestion on how we can make SOAP/AM Server even better? Add your feedback in the Comments area below or send us an Email at support@ticsoftware.com.
Donald Wickham has 31 years experience with Nonstop including 20 years for Tandem, Compaq and HP. He has been with TIC Software for 11 years in the role of Chief Architect.