|
So now you're an interim assistant commandant. When the Aviation Branch and USAALS were established in 1983, command and control of USAALS was assigned to My advanced course tablemate was the Assistant Commandant, The traffic got very heated until findings of Vice Chief of Staff, US Army study directed special study group conducted 1987-1988 prompted the Commander, TRADOC, to approve transfer of command and control of USAALS to the Aviation Branch Chief. Effective 1 October 1988, USAALS was established as a non supporting tenant activity at In retaliation Major General TRADOC scheduled their annual planning conference seven months ahead and I got notification, along with a long list of school accreditation requirements for certification renewal. We were dead in the water without computers and there is nothing worse that a “due out” when work demands a resource. General Elam had his mission and we needed to get support through our chain-of-command—so much for base operations support agreements. We got a break because Mr. Brian Collier and my wife had a long standing profession relationship—he was the TRADOC Systems Manager and provided my staff with direct automation access from the US Army Reserve Center on post commanded by another classmate, Lieutenant Colonel John Onimbo. We had two unique sergeants: Sergeant First Class Sean Gosine and Sergeant Tom Mangan—they were computer geeks. Sergeant Gozine’s wife owned a “turnkey” business that installed computers throughout the Tidewater and, once their equipment was accepted, whatever the company discarded, they got to use as they saw fit. We cleared a large room and set-up long conference tables. Armed with a copy of R:BASE 2000, one of the first relational databases I’d ever seen. With it, we established an aviation school database of all training aids, device and tools, largely the handiwork of Chief Warrant Officer Jernigan. With all of the parts inventoried, we moved on to tools, materials, data and calibration equipment and that’s when a met the most troubling General Officer in my entire career, Major General Eugene, P, Forrester—at the time he was PM Apache and probably the most ill informed, pretentious individual I had ever met—but a close friend of Mr. Cribbins! It was apparent that we could not teach students with inoperative training modules. It was even more apparent that there was a serious problem when the venerable editor of the Armed Forces Journal, Mr. Ben Schemmer, paid a call at our facility to see just how bad off the Army was and determine for his readers why mechanics left school and were not able to work at their new duty stations. Benjamin F. Schemmer, at the time editor and publisher of “Armed Forces Journal International.” Mr. Schemmer, a U.S. Military Academy graduate, and I had and served together when he worked for Secretary of Defense Robert S. McNamara at the Pentagon. In 1968, Schemmer purchased Armed Forces Journal International. For 24 years, he acted as the magazine's editor and publisher, covering the international defense industry. In his spare time, he wrote articles for various publications, including The Washington Post, the He also wrote four books about military affairs and edited the Strategic Review before it folded in July 2001.but, before his scheduled arrival, in June 1987, I went to the McDonald Douglas facility near Fortunately, Lieutenant Colonel James Brier, a former platoon leader, was well placed in the production facility and, armed with funds, transportation money and parts money, we passed our list. Much to my delight the McDonald Douglas had been contacted by Mr. Schemmer and they sent truckloads of items that, for some reason, had been stored in their warehouse. The items needed to be modified; however, we got every item the Army purchased and one hell of a lot of goodwill from Macdonald Douglas. There were lots of “warts” in our organization because so many loyalties had been based on favors from the Lieutenant Colonel Sam DeLoach, a stalwart of Mr. Cribbins, worked mightily to undermine every possible good thing that transpired. The kindest thing I can say about Colonel DeLoach was that he was undesirable on every count and quickly left allowing me to promote an extremely talented officer who had his heart in Army aviation and his priorities in order. Mr. Otis Haislip was my civilian deputy and absolutely not interested in work. He did very little and was soon out the door with a host of other Transportation Corps holdovers. Leaving Fort Eustis was bitter sweet because things were just heating up over the use of automation on small devices that the “old guard” was resisting—too much power, too far down. Our training forecast presentation was perfect! TRADOC systems were certified and we were accredited. General Elam and his crew didn’t fare as well and spent lots of time with their things and inability to use them. Newly minted Brigadier General [later LTG Gus] Pagonis exclaimed at a luncheon soon after the decision to move USAALS under the Chief of Aviation Branch: “Aviation doesn’t have a corner on the smart market and it’s good riddance from Transportation Corps. Well General, what a relief. The day before I assumed command of the US Army Service Center for the Armed Forces, then commander Colonel Robert W. Becker, had an open house to show off the passport and visa office—at the time they could not locate more than 400,000 documents that the field claimed had not been acted upon or were being processed. Since I didn’t have any official duties, I decided to ask questions about the UNIX BSDM system that was in the vault. It wasn’t connected. What I saw was a few desktop computers and 17 desks where people were assigned and very little to show—the room was freshly painted and the equipment was from HON. So far it had been my experience that very technology infrastructure is likely to have at least one system that's provided by a business solutions vendor that doesn't have an IT focus. Automated serialization, specialized engineering solutions, precision calibration machines, specialty applications--the list goes on and on. Of course, this solution is on a computer, maybe on your network, and it helps your business execute its tasks. Colonel Becker wished me well and began his life in the civilian travel industry where he had honed his skills for his final years of active duty in a paid government job. After a week, I knew that the technician who provided the solution wasn't an IT person, which can make your job a little tricky, and didn’t understand the passport or visa business. I asked to address our needs and concerns about the technology being Colonel Becker had invested our money in to get the job done. #1: How do you back this thing up? Ask this one first. If the solution runs on a computer, you need an answer to this question. Make the representative train you on the backup procedure AND the restore procedure. It goes without saying that you must have a strong backup and restore procedure, but when someone else implements the solution, you may not have much say in how (or if) IT standards are applied to the solution. Also push for a cold secondary system, if that works in the plan for the solution being implemented. Having a parallel environment (though possibly with stale data) is a plus in this situation, because there's a test environment and a complete spare parts inventory, which will extend the life of the solution. #2: What are my support channels? Get phone numbers, e-mail addresses, and Web site links. Label the system to clearly identify the chain of support. For example, you might apply a label that says, "Call Jim in Engineering first, then XYZ vendor support at 800-555-1212." Be sure to document all subscriber numbers, customer numbers, or relevant identifiers for your account and organization. Also nail down the terms of the support--a one-year warranty, unlimited support forever, etc. Most important, get a clear definition of what the deliverables are for the support you'll be receiving. Is there an onsite technician or telephone-only support? Are there response-time guarantees? #3: Who owns this equipment? When solutions are delivered, Engineering, Manufacturing, Distribution Warehousing, or other groups may not coordinate with IT to clarify important issues of ownership. For instance, your organization may be purchasing a laser plasma cutter, but it has a computer to input the calibration codes--and Engineering doesn't coordinate this entrant device with IT. Clearly identifying who owns the equipment does the following: • Establishes the support sequence of events • Answers any questions about what happens to the equipment should it be decommissioned • Sets the priority on whose needs are to be met #4: Who owns this solution? Within your organization, determine who is the owner of this solution and the backup individual(s). Ensure that these individuals can support the system for the most part on the first level. Make a concerted effort to define IT's role in the solution (if any). #5: What communication does this system need? Does this system need TCP/IP network connectivity, a modem, special serial connections? If so, outline what the system talks to and how it provides its results. If possible, implement an "island" network that's not uplinked to any other segment on your network. This will reduce the risk of viral infection. If there's a special connection--such as the feed to that laser plasma cutter--make sure there's a label on each end describing its role. Also make sure that the operators and functional area administrators are aware of this connection. #6: Are any spare parts provided? With specialty solutions, there's usually a piece of equipment that allows the system to communicate to non-computing devices when Ethernet isn't used. Identify the custom components that are required for the system to operate and then determine the requisite inventory of spare parts and how to get more if they're needed. #7: What are my options for compliance? If this system sits on your network to communicate with another system for performance data, automated interaction with other systems, or other communication reasons, you should be concerned about service pack, hot fix and antivirus compliance. Many vendors of specialty systems provide these services as an option. One service, called Managed Care Light, is a screening service available to custom solutions. Updates are screened and then local IT is empowered to deploy the available, relevant, and approved updates for special systems. #8: Who is our account/sales representative? A vendor contact is important to your IT department because it can help you manage direction. For the next version of this solution, or when it's time to upgrade, you can consider working with this individual to explore alternative options, should they be available. For example, you don't like the PC in the warehouse that talks to the laser plasma cutter over TCP/IP--why not host it as a virtual machine? The account/sales rep can get you in touch with the right people to explore this possibility. #9: Can the vendor restore the system in its entirety? It's important to ensure that the vendor can totally restore this system in the event of fire, flood, theft, etc. Consider using imaging tools like Symantec Ghost or LiveState to make sure that you have a full restoration of the system. #10: What is the decommission date/modernization/replacement timeframe? This may seem insignificant at system inception, but how long will it be here? How long does this equipment last? These are important questions, and they should not go unanswered. For example, the laser plasma cutter is on a desktop-class computer. A good estimate is to put the life at three years. If this is a mission-critical solution, two and a half years would be more realistic. (And you might want to ask follow-up questions about why it's on desktop-class equipment.) Know what the modernization paths are, if today were the decision point, so that capital funding can be made available if necessary and so that this system won't slip into the forgotten realm. Ms. Pauline Robinson said, “Colonel, we were never asked any questions and told that this was going to let us process passport and visa applications more effectively.” It took six months but by following a procedure Senior Master Sergeant After monitoring our system we discovered that we had a way-too-expensive-to-bother system that was way-too-hard-to-care for and use. I knew it was critical to be able to provide some semblance of monitoring of your systems and network. With help, we began to get information about the simple questions: • Individual monitoring scripts: • Gathering system information (complete) • CPU usage, including SMP systems (complete) • Number of running processes (complete) • RAM utilization (complete) • Up/down monitoring (complete) • Disk space utilization (complete) • Critical service monitoring (this article) • Network adapter throughput/stats Exchange • Gathering system information • Port status • Current throughput – uplink • Current throughput – per port Where will the information be stored? All of the gathered information was stored on tape drives in dBase format. The language We standardized field data using Department of State programming fields and information. Each code snippet will be easily added to the previous downloads in the series in order to add functionality to the overall system. All of the code snippets will be completely documented so that you can easily figure out what the heck is going on. You will also get a companion document (you're reading it!) with each code snippet that provides you with some examples on what is captured with each script. It would have been nice to have open-source, free product called Notepad++ for our scripting needs. It provides syntax highlighting features for a wide variety of different languages, including VBScript. Create this week's tables As an FYI, we gathered very basic information such as the number of running processes. In this code, we're gathering detailed information about all of the running processes on each system. I'm assumed that we did everything and created a table to capture the following: • Systemname: Name of the system (same as the system name in the systemlist table. • Date/time: The date and time the stats were taken. • Process Name • Process ID (unique) • Command Line: The command used to start the service. This parameter is not always present. • Page File Usage: How much of the page file is being used by this process? • Working Set Size: How much RAM is being used by this process? • Parent Process ID: The ID of the process that spawned this one. • Executable Path: The path to the executable that starts this process. This is a pah only and does not include all of the parameters. See the Command Line for more. This parameter is not always present. We were able to train and reduce the information gap and provided a piece of critical information just ahead of the Chief of Staff, Air Force commander’s conference slated for Hawaii where we had heard the natives were unhappy and going to make a stink about poor support. General Merrill A. McPeak, chief of staff of the US Air Force, wanted to understand how passports and visa’s were processed. Our automation technician installed a terminal and gave his aide access. There was no discussion of passports and visa processing delays discussion at the
|