Read the original at You and i.
Jim was relaying an interesting question he received from one of our favorite clients over in Dayton, Ohio. This particular company has fully embraced the wholesale and winning combination of acquiring data centric knowledge and skills, as well as embarking on a targeted and well managed database modernization and re-engineering project. Good for them!
The question posed goes something like this:
"Hey Jim, now that I'm a database engineer, what should I be doing day to day?"
First, this is a really insightful question. It means that the person is thinking strategically and is ahead of the curve. Well done!
The What and Why
Both reactive and proactive activities generally involve: monitoring, analysis and something else.
The something else will depend on your focus and your client (i.e. who are you providing value to).
Why you should be doing this seems self explanatory, but if it's not, consider this:
Partnering with leaders on solving data centric business problems and getting more value out of data is of the utmost importance. Doing it proactively makes YOU more valuable and your company or organization more viable.
In terms of monitoring, assume you are an investigator. You need to peek behind the curtain, look inside the black box, ask the probing questions. In short, you need to learn more about your data, the usage of data and the life cycle of data. You need to discover who is using the data and for what purpose.
Here are a few ideas to get you started. If you need more, please reach out and we can help you identify and prioritize activities that provide a good return on investment. We can also help you get better at identifying and partnering with your colleagues.
Narrow your scope to the top 10. Once you have a repeatable process, open the aperture and expand.
Profile your data. Learn more about the properties and trends of tables and indexes. How large are they. How fast are they growing. Who is using them. How are they used. Who has access to the data. How is the data accessed. When is the data accessed. Get the idea? Know your data.
Take periodic and consistent snapshots of the the query plans. Store this data and use it to develop trends. What are the longest running queries. Who is running the queries. What are the attributes of the query requests (do you see simple statements, or complex statements). Who is reading the three million results from the query run twice a day, every day (I can tell you... no one - this is an extract!).
The DB2 for i catalog is your friend. Get to know it. Use it.
Make a blueprint of your current data model. Pick a subject area or application and model the database objects, such as they are. Use reverse engineering tools and methods to be more productive. While you're at it, take this opportunity to learn a proper database modeling interface. Something that has more colors than just green.
Use the blueprint to identify gaps in your organization's relational database best practices. SQL queries are based on and driven by the data model. A bad data model means more work for the SQL query. A good data model means less work for the SQL query. If the model behaves well (i.e. well defined sets), then the SQL will behave well (i.e. good set operations).
Using the current data model and your gap analysis, define a future data model, build a new blueprint. Formulate a plan to modernize and re-engineer the database to incorporate the foundational elements that support data centric processing.
Watch and wait for an opportunity (i.e. business requirements) to implement the modernization and re-engineering plan. We like to do this on a targeted and cost justified basis. Better yet, don't wait; engage the business to understand pain points and new initiatives.
Get out of your office or cubical. Go meet people. Talk to your colleagues and clients at every level. Find out what they are struggling with. Find out what they are using the data for. Find out what the data is NOT providing them.
The information seekers in your organization are requesting data from IT. The data is extracted and downloaded to a PC. Once on the desktop, the real magic occurs. Peek behind the curtain, look inside the black box, ask the probing questions about what the data is used for and why. Better yet, ask the information seeker "what problem are you trying to solve?". This is how you get in a position to provide value on a proactive basis.
This is how you become relevant and stay relevant.
Well... what about you?
I recommend you strive to learn something new every week. Take an hour (or two) each and every week for yourself. Crack open the SQL Reference manual. Initiate a project for yourself. Do a proof of concept or proof of technology. Develop and hone your soft skills.
All work and no play makes Jack a dull boy.
Read the original at DB2 for i.
It is 20i4, and we are still a bunch of whiners. What a sad state of the community. IBM i was branded in 2008, to represent a new evolution in our world. The hardware was now Power Systems, and our beloved platform was morphed into an operating system. Yet, six years later, we are still complaining.
Is it just because we are a bunch of old farts blowing in the wind? We did have passion for this platform once before. When the AS/400 was released, no one called it a S/38 or a S/36. Yet today, the same people who were so gung ho about the amazing AS/400, seem to have got stuck in the last century. With Power Systems, IBM i has evolved into an even better OS, become more integrated, can run inside a Pure System, and continues to evolve. What happened to the passion of all those AS/400 gung hos? Did it all just dribble out below the chair you are stuck in?
Just this week, a community pundit made the claim that if IBM gave them a commitment for at least ten years for IBM i, he would start calling it by the correct branding. This smacks of two nonsense things. First, starting about eighteen months ago, prominent IBM speakers showed charts with a commitment beyond 2025. The nonsense here is that this particular pundit is actually contributing to the world about the platform, yet has apparently missed one of the biggest stories yet? Second, the IBM i brand has now been with us for six years, and the AS/400 has been gone longer (14 years) than it was sold by IBM (12 years). Some of the community took six years to adopt the iSeries brand after the AS/400, so I expect we should see a turnaround in 2014. The nonsense here is that IBM’s branding is what matters, not what is deemed by an individual pundit to be “right” – especially when that pundit has ZERO marketing and branding skills.
All over the web, the IBM i community is flailing. The stubborn ignorance of the AS/400 Professionals LinkedIn group means we can still wallow in the past for as long as we like. And the complaints! Oh, the complaints. Even on the IBM i Professionals LinkedIn group there are a bunch of excuses and inane justifications about why we should still use the old branding. It is simply complaining. Whining. Seriously, it serves only one thing – that is, the outside IT community looks at the IBM i community and laughs. The platform detractors continue to use this against the platform – quite amazing, when you think how the platform can do so much that its own community does not even know all that it can do.
It is so obvious what needs to happen. Education. We need to combat the ignorance of the dark green ages, and bring the community into 20i4. For starters:
The AS/400 is dead.
IBM i is an operating system.
IBM i runs on Power Systems servers.
But are those living in the dark green AS/400 cave willing to venture out? For those who are listening, for those who have passion for IBM i, let’s plan on 20i4 being the year of education. Let’s spread as much information about IBM i as possible – its legacy, its capabilities, its future.
Are you up for it? There are a bunch of senior citizens who need their hand held while they grumble as they waddle into the light.
Read the original at Angus' Blog.
Read the original at iDevelop.
Read the original at i Can.
A sitemap is exactly that -- a map that search engines read to find what is on your website.
Sitemaps are a simple way of keeping the main search engines like Google or Bing up to date with what is going on with your website. I mean, why bother writing a website if nobody every reads it right?
The XML sitemap module creates a sitemap that conforms to the sitemaps.org specification. This helps search engines to more intelligently crawl a website and keep their results up to date. The sitemap created by the module can be automatically submitted to Ask, Google, Bing (formerly Windows Live Search), and Yahoo! search engines. The module also comes with several submodules that can add sitemap links for content, menu items, taxonomy terms, and user profiles.
I can almost guarantee that you are reading this because you searched for something on a search engine and it bought you here. It only knows about this website because of the website map 'sitemap.xml'
The sitemap is pure XML (a kind of funky HTML) and basically lists everything that is on the website and looks something like this:
Read the original at Geekish Garrulous Grumblings blogs.
If you are using the IBM i HTTPAPI (LIBHTTP) opensource utilities, you already realize how easy it is to talk to a webservice from within your RPG programs.
But remember, after you have run your program, you will have a beautiful log of the entire SOAPey process stored in an IFS file in your temporary folder -- assuming you are running in debug mode.
So , in your program make sure you are turning on debug:
// Note: http_debug(*ON/*OFF) can be used to turn debugging // on and off. When debugging is turned on, diagnostic // info is written to an IFS file named // /tmp/httpapi_debug.txt /if defined(DEBUGGING) http_debug(*ON); /endif
and then after you have ran it you can see the results by typing: dsplnk '/tmp/httpapi_debug.txt'
You will see a gloriously detailed log that looks something like this:
Read the original at Geekish Garrulous Grumblings blogs.
As we pass AND approach the various new year thresholds, this is a time when most of us symbolically reflect on the past, and plan for the future. This has been practiced for centuries in cultures all around the world.
While crossing the seasonal threshold and moving from one year to the next, there is a long standing tradition of making (and breaking) a resolution. Many of these annual resolutions involve a promise to do less, do more, or do better.
According to Merriam-Webster the definition reads...
res·o·lu·tion noun \ˌre-zə-ˈlü-shən\
: the act of finding an answer or solution to a conflict, problem, etc.
: the act of resolving something
: an answer or solution to something
: the ability of a device to show an image clearly and with a lot of detail
I really like all of these explanations, and believe they apply very well to what we need to do as IT professionals (your personal resolutions are your own business).
When I reflect back on what my team has witnessed in countless IT organizations around the world, a few clear and distinct things come to mind.
Every business leader wants to have (IT) solutions that are:
To meet these requirements, new tools, new techniques and new approaches need to be embraced. And if you ask me, doing so without throwing the baby out with the bath water. In other words, keeping what works and re-engineering what doesn't. Rarely do we find that it is cost effective or advantageous to start over from scratch. Some might call this approach "evolution, not revolution". The pace at which you evolve is a function of time, energy and funding. I would also throw in will power.
From a data perspective, business leaders want more relevant information. They want to move from data being the static and benign byproduct of a transaction or event, to data being the raw material that is refined into insightful information; something that provides a unique and otherwise hidden perspective on what's happening, what's coming, what's needed.
For many (most?) of my clients, it seems that data is dragging them down like some kind of massive anchor. A huge bucket of bits that is increasing in weight and volume, forever tugging on the organization's precious resources.
For a few keen companies, data is an enabler. This byproduct of their transactions or events will serve an important purpose. That is to become a lens to focus the past, and for looking into the future. Their data becomes an asset; something to be preserved, treasured and made useful. Something that becomes a unique advantage to their business, their partners and their customers.
Approaching Information Management Differently
Another major trend we see is that increasingly, the formal IT organization is being bypassed. Or at best, relegated to being just the conduit for data. This means that the effectiveness and more importantly, the value of traditional IT organizations is being eroded.
We see more and more business users acquiring information technology solutions directly - deploying and using them without the assistance or oversight of the IT organization. Obviously there are many concerns with this trend. The one I want you to focus on is: irrelevance. As in, your knowledge, skill and expertise are irrelevant, no longer required.
Increasingly, users have access to the data. The various lines of business have growing requirements for information. If IT cannot provide the information, then they are asked only to provide the data. Sooner than later, the "value add" of IT will dry up. To be sure, IT should have a vital part to play in the acquisition, storage, management, and productive / safe use of data. But given the current trend, how do you stay relevant? How do you continue to provide value?
One idea I have been sharing with my clients involves a change in philosophy and approach. In terms of engaging your business leaders, users and colleagues, move towards a consulting oriented discussion instead of service oriented discussion. As a consultant, you are in a position to guide and influence the community around you. And don't wait for them to come to you. Be proactive. Go to them. This is what makes you valuable and keeps you on the list of critical success factors.
Find a way to help, not hinder.
For the coming year, let me suggest that you persevere to:
- Stay relevant
- Make and maintain a connection with your
- Provide real value
To accomplish these things (from an information management perspective), I recommend you personally resolve to:
- Learn more about the science and art of information management
- Gain control and governance of data and data access (don't be a Target)
- Get better at the design, architecture and modeling of database solutions
Happy New Year!
Read the original at DB2 for i.
Read the original at midrange.com job board Job Site.
Read the original at i Can.