[259] Management of the multifarious elements of the Saturn program entailed new tasks and concepts beyond the scope of any previous rocket program. As explained in chapter 9, MSFC's management was a dynamic process. Although rooted in the experience of the von Braun team, dating back to the 1930s, Saturn management responded to internal stimuli as well as external influences, including the prime contractors, NASA Headquarters, and other sources.
Almost last, but far from least, the challenge of transporting rocket stages of exceptional size to test and launch sites posed equally unique complications. Logistics became a special management task. Chapter 10 explores some of the ramifications of moving the Saturn stages from points as far away as the Pacific coast to the launch pad at Cape Kennedy, with intermediate stops for static-firing tests and other checks.
[261] In 1962, pausing to look back over a career in which he played a key role as a leader in rocket research, Wernher von Braun noted two significant factors of success. First, the group of German rocket experts, known as the von Braun team at NASA's Marshall Space Flight Center (MSFC), had been a "fluid, living organization," shaped by and responding to external forces. Second, in three decades of consistent activity at the forefront of rocket development, an activity conducted with a "singleness of purpose, we have had only one long-range objective: the continuous evolution of space flight," von Braun emphasized. "Ever since the days of the young Rakentenflugplatz Reinickendorf in the outskirts of Berlin in 1930, we have been obsessed by a passionate desire to make this dream come true." Despite the changes over the years in personnel, in geography, in nationality, and in bureaucracies, von Braun continued, "many of our methods have remained unchanged."1 Many of these methods would persist during the Apollo-Saturn program and carry over into other phases of management at Marshall Space Flight Center.
No major Saturn component, whether engine, stage, or instrument unit, evolved without numerous-and continuous-problems. The persistence of various snarls is easily perceived by dipping at random in von Braun's "Weekly Notes" or "Daily Journal" from 1961 through 1970. Predicaments occurred everywhere and every day. Although complications in the Saturn program lingered, it is apparent that the most annoying problems tapered off during 1966. With increasing frequency, entries in the "Weekly Notes" and "Daily Journal" reported tests "successfully accomplished," results "well below red line," and hardware with "component qualification complete."2
[262] The rising note of technological optimism in the Saturn program stemmed from the elaborate research, development, and test programs, followed by carefully controlled fabrication and manufacturing guidelines instituted by both NASA and contractors and managed by MSFC.
As Director of the new Marshall Space Flight Center in 1960, von Braun faced some immediate managerial challenges. The core of the staff had come from ABMA's Development Operations Division, which he had directed for the Army. But that division had been a research and development group depending on other ABMA offices for ancillary support and administrative services. After the transfer to NASA, the MSFC director had to develop an administrative as well as technical staff, in addition to providing procurement contracting, facilities engineering, and other support services. The von Braun team not only found itself in a civilian organization for the first time, but also the style of operations had changed. There were new responsibilities for numerous projects, as opposed to the ABMA experience of dealing with only one prime project at a time.3
In spite of the increased responsibilities under the MSFC organization, management retained a distinctive in-house capability-what von Braun liked to call the "dirty hands" philosophy. This attitude, resulting from years of active work as a research and development group in Germany and from the Army arsenal concept of the ABMA days,....
[263].....provided a number of exceptionally strong laboratories and shops at the Huntsville facility. Managers and engineers were never very far from each other, and the relationship (and its elaboration) persisted as a key element in the success of MSFC's management of the Saturn program.
Technical competence was more than a catchword at Marshall; it was a way of life. As Director, von Braun somehow succeeded in keeping up with the paper work and budget reviews involving NASA and his own center, and at the same time, he kept an eye on minute technical details of the Saturn program. In 1967, for example, when von Braun received a weekly note on propulsion systems, he noticed that inlet pressures for the S-II center engine had been simulated at 1900 grams per square centimeter (27.0 pounds per square inch adiabatic) during J-2 engine tests. In the margin, von Braun jotted a note for one of the project engineers: "If I remember correctly, that would enable us to lower the LH2 tank pressure in the SII by 2 psi...right? What are the SII people now actually doing?"4
Throughout his tenure as Marshall's director, von Braun required such "Weekly Notes" from the laboratory chiefs and program managers, as well as from other personnel on an ad hoc basis when a problem was brewing. He was adamant about the length of these Weekly Notes, warning "notes exceeding one page will be returned for condensation." As the notes crossed von Braun's desk, he emphasized various points with check marks and underlined phrases and scribbled assorted messages in the margins: a compliment; a request for information; dismay; encouragement; and miscellaneous instructions. Reproduced copies went back to the originator with marginalia intact. Although curt and to the point, the replies were invariably personal, and occasionally tinged with humor. Informed of a possible strike by the janitorial contractor, von Braun responded, "Get me a broom! I'll sweep my own office."5
At the innumerable meetings attended by von Braun as chairman or participant, he displayed a remarkable ability to distill complex technical issues into terms that other participants could understand. Matt Urlaub, S-IC Program Manager, recalled technical presentations "that lost me in the first five (minutes)." After listening, von Braun would sum up the presentation in language clear to everyone. Yet von Braun consciously avoided dominating such sessions and attempted to bring out all opinions. These techniques contributed to genuine "team spirit." Konrad Dannenberg, a key manager and associate of von Braun since the days at Peenemuende, stressed the point: "You have to get all the people involved. Von Braun has a real good flair for that," he said. "Everyone, when he has a meeting with him, feels like the second most important man... and boy that really gives you a team spirit. Everyone is willing to do his best." Von Braun employed this trait effectively during tours of Marshall laboratories and contractor plants. He met with senior executives, but he also took a personal interest in what was happening on the [264] shop floor-the problems, the progress, and the tools. Von Braun talked just as easily with the "top brass" as with the "tin-benders." These tours had great significance in improving morale, and von Braun made periodic tours intentionally. The tours were helpful to him too, in sensing the pace of the program as well as the nature of difficulties as they developed.6
This concern for technical aspects was a hallmark of Marshall planning, and von Braun personified it. In the earliest phase of Saturn design at ABMA, Frank Williams, an ABMA veteran, remembered von Braun's consistently close involvement. "It was just a ball working," Williams said, "having him [von Braun] come down and literally pore over the drawing boards with you, and look at the performance and check the engineering work." Williams went on to say that when the Saturn V design was being established, von Braun was in the forefront, immersing himself in the whole vehicle: structures, systems, and missions.7 This is not to say that only the Director and a small handful of top aides did the conceptual work and forced it through. One of the reasons for the Saturn success, Dannenberg emphasized, was "because a lot of real good down-to-earth planning was done at the beginning." Von Braun solicited advice and suggestions from workers in the shops, taking into account the realities of fabrication and manufacture as the design evolved. In this way, Dannenberg explained, von Braun avoided the pitfalls of having top-level managers making critical decisions among themselves and making assumptions about production that might not approach reality.8
These tenets, among others, guided von Braun and his staff at Huntsville. Many other issues of organization, administration, and accountability had to be solved. The Saturn program was large, expensive, and involved complex contracts. According to one source, von Braun remarked that when he came into NASA, he knew how to go to the moon, but he did not know what a billion dollars was.9 Like other NASA administrators, von Braun soon learned to handle billion-dollar programs with aplomb.
Eberhard Rees, who succeeded von Braun as MSFC's Director in 1970, said that when the Apollo-Saturn program was inaugurated in the early 1960s, the adolescent NASA organization had no comprehensive management apparatus; the management system developed "after some painful experiences" during the early development period. The management organization for the overall NASA program, as well as for MSFC, was not set up in a flash of insight, to remain unchanged for the duration of the program. Rather, as the program gained momentum and the configuration of the launch vehicles began to evolve, management [265] organization and tools also evolved, changing the programs over the years. As Rees observed, one of the axioms in the evolution of a large development project was that no static system of management would suffice.10
During January 1960, when affiliated with ABMA, von Braun and his staff began to set up a management plan that would meet the approval of NASA Headquarters. The laboratories would continue to report directly to von Braun, and a new organizational position for a project director of the Saturn vehicle system was proposed. Details of vehicle integration, planning for R&D, and mission payloads were worked out through a separate Saturn coordination board, chaired by von Braun. The arrangement was rather unwieldy, and was never completely implemented. However, the correspondence from Huntsville to Washington requesting approval reveals the strong influence of NASA Headquarters in early Saturn planning, including details of contractor selection. The early influence of the laboratories and their chiefs is also evident in the membership of the "working groups" that made up the Saturn coordination board.11
The management organization for the early period of the Saturn program, when the Saturn I was the only launch vehicle being developed, relied on the Saturn Systems Office (SSO). At the heart of SSO were three project offices: Vehicle Project Manager; the S-I Stage Project Manager; and the S-IV and S-V Stages Project Manager (the S-V was a small third stage that was ultimately dropped from the Saturn I configuration). The vehicle project manager cooperated with the stage managers in overall vehicle configuration and systems integration. The Saturn I first stage was produced and manufactured in-house by MSFC at Huntsville, and the production of the upper stages as well as the engines and the instrument unit involved management of several other contractors. The SSO was a comparatively small office; in the spring of 1963 it employed only 154 people. Its operation was based primarily on the strength of other center administrative support offices and the work of the "line divisions." The line divisions were based on the nine technical divisions, or laboratories (each composed of several hundred people), carried over nearly intact from the ABMA days.
The laboratories themselves carried significant prestige within the center and benefited from very strong support from von Braun. In fact, most technical decisions were reached by consensus during the "board meetings" of von Braun and the laboratory chiefs in executive sessions. For the lower stages of the Saturn I vehicles, produced in-house, this arrangement proved workable; and it must be remembered that the laboratory chiefs had worked this way for years, first at Peenemuende and later at ABMA. Much of the work in SSO concerned funds and liaison with NASA Headquarters. This was conducted in a very informal manner, with SSO personnel frequently visiting Washington.12
[266] The growth of the Saturn program to include development of two new launch vehicles caused a reappraisal of the production and management organizations. The finalization of plans during 1962 for a two-stage Saturn IB (for Earth-orbital manned Apollo hardware tests) and the three-stage Saturn V (for the manned Apollo lunar landing missions) enlarged the scope of SSO and prompted the shift of MSFC into a more comprehensive management role. The change was underscored by von Braun in remarks to a management convention in 1962, when he observed that "our rocket team has become today more than ever a managerial group." The Saturn IB and Saturn V manufacturing programs were far beyond the in-house capability of MSFC and available government resources, so that large-scale contracts under MSFC management were required. The von Braun group had some experience in the practice of accomplishing tasks through contracts. Outside of Peenemuende, important research work involving the V-2 was done by German universities in aspects of propellants, trajectories, and propellant systems. German industry also contracted for research and development of guidance and control systems, as well as turbopump machinery. The von Braun team had developed managerial skills in working with American contractors who built the Redstone, Jupiter, and Pershing missiles. Because of the size of the Saturn program and the diversity of the major contractors and subcontractors from coast to coast, a different management organization was required. The task of developing and integrating two or three large, complex stages and an instrument unit into a single vehicle that would mate with the spacecraft and launch facility was compounded by the multidisciplinary problems of weight, size, and manrating. The complexity was further increased by budgetary constraints and tight schedules. In responding to these new demands on management, both MSFC and NASA Headquarters changed existing agency techniques, developed new ones, and remodified techniques in response to changing conditions.13
The reorganization of SSO in 1962 combined the similar Saturn I and IB vehicles under the management of a single office, established the Saturn V Launch Office, and set up the Saturn-Apollo Systems Integration Office. The reorganization further incorporated a new emphasis on these "project offices," that were empowered to draw directly from the expertise of the technical divisions. Internally, the technical divisions of MSFC did not change much more under the new NASA organization and continued to report directly to von Braun. As before, divisions were not designated specifically to projects, but were organized by professional disciplines-electronics, mechanical engineering, flight mechanics, and so on. Each division director had the responsibility to maintain a high level of expertise in his organization, keeping up with work in industry and other government agencies and carrying on theoretical research. Von Braun reminded everyone, "The technical people [must] keep their [267] hands dirty and actively work on in-house projects selected specifically for the purpose of updating their knowledge and increasing their competence." These practices were necessary to enable MSFC to comall phases of development, production, and shop work. Von Braun emphasized that this policy was the best preparation for evaluating contractor standards and proposals. The goal was to achieve the best economics in overall work and to get the maximum results for taxpayer dollars.14
Von Braun noted in a memo on the reorganization, "It is important to spell out the responsibilities of the project offices in contrast to those of the technical divisions." The project offices managed efforts involving more than one discipline and reported directly to von Braun. Because of the technical complexity and scope implicit in project management, each office required technical support in depth. "It gets this support, not by creating it within its own organization, but by calling upon the technical divisions," von Braun wrote. He left no doubt about the vigorous role of project managers in the future operations of MSFC: "Since the direction of the various projects assigned to our Center constitutes our primary mission, I would like to make certain that Division Directors fully understand and fulfill their responsibilities in support of the management of those projects."
The 1962 MSFC reorganization reduced the premier position of the technical divisions, or laboratories, and marked a historic break in the evolution of the Peenemuende group. As Bill Sneed recalled, the change was "painful" for von Braun to make. In his three-page memorandum explaining the change and the reasons for it, von Braun urged personnel, especially his division heads, to accept gracefully their changed status. "In the past, such a paper was needless," he wrote, and went on to explain the requisite logic for the new management responsibility in the program and project offices. "By keeping these principles in mind, and maintaining the spirit of teamwork which has been our tradition, we can adjust to our new conditions and retain our past performance standards."15
As the momentum of the Apollo-Saturn program increased and the activities of NASA Headquarters proliferated in response to the manned lunar landing program and other programs, a major reorganization was planned to cope with all the expanding operations. The reorganization involved all the major centers taking part in the Apollo-Saturn program,16 and the change at Marshall Space Flight Center set the style for its operations for the next six years, the major period of Saturn V development. The change at MSFC strongly reflected past organizational arrangements, but also increased the authority of certain segments of the managerial structure. In addition, the change established successful new working arrangements between NASA Headquarters and MSFC, as well as within MSFC's new organizational framework.
[269] Effective 1 September 1963, the center director's office (with appropriate staff and functional offices) directed two new operational elements: the Research and Development Operations (R&DO) and Industrial Operations (IO). Both of the new organizations possessed equal operational authority, and both reported directly to von Braun as Director of MSFC. Operations between the two organizations, however, were continuous, and certain elements on the Industrial Operations side had a direct continuous relationship with NASA Headquarters.17 The new director of R&DO, Herman Weidner, was a long-time member of the von Braun team from the Peenemuende era-a man with whom the other von Braun team veterans could work. The new IO director, on the other hand, came from industry, and reflected IO's contractual and managerial functions. The first IO director was Robert Young, formerly of Aerojet General. He played an interim role for about a year, and was succeeded by General Edmund O'Connor, on leave from the Air Force.18
Young's decision to accept the job had delighted von Braun. Young seemed to have the managerial talents and industrial know-how that management of the Saturn program demanded.19 For personal reasons, Young decided to go back to Aerojet, although some insiders at Huntsville thought that he found it somewhat difficult to adjust to Marshall's style of operations. Executives at Young's level still had to clear many decisions through NASA Headquarters, as well as through von Braun's office; managers coming into Marshall from private industry frequently found the additional bureaucratic layers to be irksome. Also these executives soon found that some subordinates at MSFC frequently disagreed with the boss, even in large meetings. To some executives, this bureaucratic democracy could be unsettling. In any case, the appearance of Edmund O'Connor reflected an interesting tendency to bring on board a number of Air Force officers with managerial credentials. Despite its Army heritage, MSFC seemed to favor Air Force personnel in several key positions. They not only had experience in the ways of government bureaucracy, but also had more experience in managing large, complex missile systems, compared to the Army's responsibilities for smaller, artillery-type rockets.20 In the autumn of 1964, the Air Force transferred 42 field-grade officers to various mid-level management jobs throughout NASA. Experienced in technical program management, these officers were especially versed in configuration, program control, and quality assurance. Marshall Space Flight Center received a dozen Air Force officers, with the rest sent to Houston, Kennedy Space Center, and George Mueller's office at NASA Headquarters.21
Whether the new MSFC missile managers came from the Army, Air Force, civil service, or private industry, they still had to function within the administrative framework of the 1963 reorganization agreed to by [270] Marshall and NASA Headquarters. At MSFC, the two major components that had to mesh were R&DO and IO.
In essence, the R&DO laboratories were direct descendants of the older technical divisions, and the Industrial Operations elements were modifications of the former Saturn Systems Office. At the heart of the Industrial Operations organization were the three program offices, established for the direct management of the industrial contractors who had responsibility for the Saturn launch vehicles: the Saturn I-IB Office, the Saturn V Office, and the Engines Office. The function of the new Engines Office was to shift responsibility for engine development and production from the laboratories to Industrial Operations, in keeping with the intent of the 1963 reorganization for better management control by means of program and project management.22
Each program office was set up similar to the Industrial Operations organization, so that each program manager had a cluster of small, dual-purpose staff and functional offices in addition to the project offices for technical management. Some closely structural elements were combined. The Saturn V Program Office, for example, managed the S-IVB stage, used on both the Saturn IB and Saturn V. Similarly, because some engines were used in more than one stage or vehicle, direction of the engine program was more effectively guided from one responsible Engine Program Office.
Arthur Rudolph, head of the Saturn V Program Office, emphasized that the managers of the staff and functional offices were not simply staff but were equal to the project managers for each of the project offices under Rudolph's jurisdiction. The staff and functional offices had multiple roles because they supported not only the program manager but each of the project management offices, and they interacted with NASA Headquarters as well.23 The staff and functional office managers were known informally in NASA circles as the "GEM Boxes" after George E. Mueller, who headed the Office of Manned Space Flight.
Formal guidance and direction from Headquarters to the centers came down through the Associate Administrator for Manned Space Flight, to the center director, and to the program manager, but daily informal management was accomplished through the GEM Boxes, who provided a "mirror image" between Headquarters and the centers.24 The GEM Boxes in the centers, identical to those in Mueller's office in Washington, facilitated a daily, and free, flow of information in both directions. "Since like persons were talking at both ends," commented one long-time observer of the system, "confusion and misunderstanding with accompanying loss of time and funds were held to a minimum." The impetus for this aspect of the managerial apparatus primarily came from Mueller. During visits to MSFC, Mueller emphasized to von Braun that the laboratories (R&DO) were going to have to adopt more of a support [271] role in the new program management structure, and that better communications with Headquarters through IO were urgently required. Mueller felt that the centers in general were too independent in their relationships with Headquarters and that lack of regular communications was a serious shortcoming. "So I put together this concept of a program office structure, geographically dispersed, but tied with a set of functional staff elements that had intra-communications between program offices that were below center level and below the program office level so as to get some depth of communications," Mueller said.25
Following the 1963 reorganization, the new program office began to formulate a mode of operations. As head of the Saturn V Program Office, Arthur Rudolph called on considerable managerial expertise in project management of rocket vehicles dating back to the years at Peenemuende, and especially during the ABMA period when he served as project director for the Army's Redstone and Pershing programs. From 1961 through 1963, he had worked at NASA Headquarters, in the Systems Engineering Division of the Office of Manned Space Flight. He had watched the plans for the Saturn V evolve and was aware of such factors as schedules, funds, and performance requirements.26 He also had specific ideas of how his program was going to run and placed considerable emphasis on what he called program element plans. Rudolph's staff often chafed under the requirements to write up these rather specific documents, which detailed what each office was going to do and how it was going to be accomplished. Most of the skeptics finally came around, however. The program element plans forced people to think about the goals and mechanics of their respective operations and how their operations interacted with the operations of other offices. Even if the authors seldom referred to the documents, they proceeded with greater success because they were forced to analyze the procedures from the start of the project. "I think the major problem is that in a big program like the Saturn V you have many people involved and usually people want to go off on tangents," Rudolph explained. "And the biggest problem is really to get them all to sing from the same sheet of music, to put it in the simple fashion. That's the biggest problem."27 James T. Murphy, who acted as Rudolph's deputy manager of the management division, summarized the role of his chief: "In its simplest concept, a program manager, with a supporting staff, has been designated to coordinate the efforts of all Government and private industry groups in developing and producing the Saturn V launch vehicle."28
A major instrument in establishing a managerial approach was the Saturn V program control system plan, originated by Rudolph's office in 1965, and known as Directive No. 9. The objective was to establish a "baseline definition," against which progress could be plotted, problems highlighted, corrective actions taken, and management kept informed.
Directive No. 9 instructed personnel in the Saturn V Program Office to implement the management approach in five major areas:
The baseline definition was primarily geared to matters of cost, schedules, and performance, and was achieved through program elements such as logistics, finance, and testing. The program elements comprising the baseline definition were under the control of the staff/functional offices known as the GEM Boxes:29
The interfaces to be controlled throughout the Saturn program, such as those between stages, between the payload and the vehicle, and between the vehicle and the launch facilities, seemed limitless. With contractors and three major NASA centers in the Apollo-Saturn program, the interface problems covered physical, functional, and procedural areas, and these problems often became intertwined. The necessary documentation included both drawings and written directives to establish basic responsibilities as well as the limits of responsibilities for the parties involved. Once established, such documentation could not be altered unless all parties came to agreement on terms.
The interface aspects were established at the beginning of the Saturn V program with collaboration of appropriate inter-center coordination panels, working groups within MSFC, contractor advice, and a strong input from the R&DO laboratories at MSFC.30 When a contractor originated an engineering change proposal against the current configuration, he knew in advance the impact on other equipment and organizations, since the interface documents were already drawn up. Contractors had the opportunity to coordinate possible changes ahead of time by notifying related personnel of the time of the change and its ramifications.
Difficulties often cropped up during the process of interfacing various stages of the launch vehicle, spacecraft, related equipment and systems, and the various centers. To maintain configuration control, a group of inter-center coordination panels was established to resolve the interface problems. Technical personnel were appointed from the centers and from other NASA agencies. The formal communications media between panel members involved the interface control documents. The documents were divided into two levels: level A documented technical interfaces between the centers and level B did the same for hardware supplied by the NASA contractors. If the change concerned a single stage and involved no other interfaces, then the proposal could go through a change board at the project level at MSFC. If the change affected the interface with hardware on a different stage, it had to go to the program level (level B). If the change affected the program of a different NASA center, it was necessary to go through the inter-center coordination panel [275] to reach a decision (level A). In situations where the panel could not reach a decision, an executive group, the Panel Review Board, supervised and adjudicated the issues as necessary. The Board was chaired by the Apollo Program Director at NASA Headquarters and channeled its decisions back through the appropriate centers and program offices.31
Within MSFC itself, there were a number of "working groups" that originated early in the Saturn program to cope with various development problems that had cropped up. These groups became the acknowledged elements to work on the various interface problems concerning Huntsville's work on the Saturn program. The working groups were originally created in 1960 by Oswald Lange, who at that time headed the Saturn Systems Office, "to make available the experience of MSFC and contractor representatives toward the solution of stage interface and system problems." The purpose of the groups was not to deemphasize the responsibilities of other MSFC organizations or those of the contractor, but to monitor special areas and make informed, incisive recommendations through appropriate channels. The number of such working groups varied from time to time, with each group chaired by a senior technical authority from one of the laboratories, and including representatives from the appropriate program offices. Group recommendations were channeled through the Program Office Configuration Control Boards.32
To gauge the status of the program and to assess its progress, hundreds of MSFC personnel engaged in various levels of daily, weekly, and monthly staff meetings. Although informal contact between Saturn V Program Office personnel and contractor personnel occurred daily, in addition to recurring visits to contractor plants, the most important formal meeting was the Contractor Quarterly Project Review beginning in late 1964. In these meetings, contractor and MSFC managers reviewed not only the technical status of the project, but also the management status. In the meantime, the Saturn V program manager's office customarily held various staff meetings with each of the project managers in Huntsville, and also conducted a more elaborate monthly Saturn V Program Review with all of the project offices involved. These sessions, begun early in 1965, kept the program manager fully informed and provided an additional forum to cope with related problems. Rudolph did not like frequent staff meetings. Instead he liked to have fewer meetings in which the programs were discussed and analyzed in depth, leaving the management burden in the interim primarily on the shoulders of his project offices. This meant that the monthly sessions were very long indeed, and one of the standard jokes in Rudolph's office involved bleary-eyed project managers, in the early morning hours, dropping notes out of office windows: "Help me-I'm in a Rudolph meeting!"
These monthly sessions helped to generate information for the Management Council meetings for the Office of Manned Space Flight [276] (OMSF), convened by the Associate Administrator at NASA Headquarters each month, or as required. For these meetings, the program managers and other designated personnel accompanied the MSFC director and participated in analyzing problems and progress, while at the same time receiving Headquarters information on policy changes and various program directives. The format was usually concerned with four main issues:33
In addition, two other top-level meetings were customary in the Saturn program, one within NASA management and one that included the contractors. OMSF conducted an annual Apollo-Saturn program review attended by NASA Administrator Webb and selected staff. The center directors attended, and formal presentations were made by designated senior executives from the centers. These annual reviews gave the Administrator a comprehensive and critical analysis of contractor and program performance over the past year, with projections for the year ahead. As required, George Mueller occasionally convened what he called the Apollo Executive Group. This group involved the chief executives of the contractors in the Apollo-Saturn program. They met at various major contractor sites for briefings and visited each of the major NASA centers. Mueller said that without the Apollo Executive Group, "we would not have been able to succeed-it was one of the things that made it possible to succeed." All of the chief executives became aware of the problems and possibilities, and felt involved in the program. The meetings also gave NASA and the centers "top level interest and support."34
At a different level, the Saturn program used a technical review system to ensure that development, design, fabrication, and test activities for each stage were properly evaluated. These reviews, such as critical design reviews and flight reviews, were attended by senior technical experts and top management.
Aside from the various communications, visits to the contractor facilities, and quarterly reviews with the contractors, the Saturn V Program Office had immediate representation at major contractor plants.....
....in the form of the Resident Manager's Office (RMO), which consisted of the head of each office. At each location, the RMO operated as a "mirror image" of the respective project manager back in Huntsville. The RMO was directly responsible to the project manager, and communicated with him daily. Each RMO had a small staff of technical and contractual personnel from MSFC and, as the primary liaison between MSFC and the contractor, exercised a reasonable amount of authority.35
Since the role of the RMO was to expedite decisions, a small cadre of specialists was "to assure that project management interests were advanced and that decisions were made and implemented within the designated scope of authority of the resident group." Guidelines supplied to the RMO allowed him to make certain on-the-spot decisions with the backing of his staff. These decisions included making commitments in behalf of other offices and/or functions of the center. "This resident element proved to be a most important link between government and contractor activities in the management of large programs." In MSFC's opinion, the process of management was accelerated as a result of this on-site authority, and provided a "dynamic interface" between MSFC and the contractor.36
Eberhard Rees admitted that the surveillance of contractor operations, as well as their management, was "somewhat sensitive from the point of view of the contractor." In many instances, contractors felt that [278] they should be allowed to go their own way after the contract was signed.37 The longing for more freedom of action was evidently a legacy of the experience that most Saturn contractors had previously had with Air Force contracts. Huntsville had great technical competence; at certain managerial levels of design and manufacturing, grumped one highly placed contractor executive, Marshall maintained a one-on-one surveillance. The Air Force, he said somewhat wistfully, was "not in your pants all the time."38 But Rees maintained that loose reins on the contractor had not always worked out well from the MSFC point of view. "Consequently," he said, "it became clear that close and continuous surveillance of the contractor operation was required on an almost day-to-day basis." The extent of the surveillance was proportional to the subtleties and problems of the program, its relative position in relation to the existing state of the art, and the extent of expertise possessed by MSFC. The contractor's reaction to this aspect of NASA monitoring was not favorable at first, but eventually this "penetration and monitoring" was perceived to be a mutual benefit characterized by the often repeated phrase, the "government-industry team." "Contractor penetration" was an important concept that ultimately involved the contractor's relationship with his own subcontractors.39
One of the most interesting aspects of contractor penetration was the RMO approach. NASA could exert considerable influence on technical decisions that affected the managerial organization of the contractors. General Samuel C. Phillips, who directed the Apollo Program Office at NASA Headquarters, revealed this leverage during one of the program review sessions held at NASA Headquarters in 1964. He noted that various contractors had strengthened their organizations during the preceding year, "either on their own or due to appropriate influence by NASA."40
Phillips's comment on the use of appropriate influence was an understatement, since MSFC could, and did, force contractors to change their modes of operation. In 1963, the development of the S-IVB was in its dual role as the second stage of the Saturn IB vehicle and as the third stage of the Saturn V. This duality posed something of a problem of interfacing for the S-IVB prime contractor, Douglas Aircraft Company. Discussing the S-IVB project during the 1964 program review, Lee James pointed out that MSFC management wanted to make sure that Douglas did "not see two faces at Marshall. It is important they see only one." As far as the contractor was concerned, the Saturn IB/S-IVB manager acted as deputy to the Saturn V/S-IVB stage manager, placing basic responsibility in the Saturn V Program Office.41
During his presentation, James spoke on the subject of "Saturn I/IB Launch Vehicles and Related Facilities," in which he noted that management constituted a "major part of the problem." Moreover, he continued, "a major part of that problem was considered to be with Douglas."
[280] Douglas had never set up a project-oriented organization, James explained, and the management structure in operation never worked very well in any case. The crux of the difficulty seemed to be the company's Sacramento Test Facility (SACTO), set up as a part of the engineering manufacturing divisions, with ties to both Santa Monica and Huntington Beach. As a result, James said, there was no place "to pull their organization together" to make sure programs like the battleship test and the all-systems test evolved smoothly and logically. Management at MSFC stepped in to remedy the situation. James put it bluntly: "We forced Douglas to reorganize Sacramento into a separate entity." As a result, SACTO reported directly to the upper echelons of Douglas management, and MSFC was involved in the reassignment of Douglas's Deputy Director of the Saturn Program to the new position of Director of Sacramento Test Operations, a further benefit to the reorganization. To enable MSFC to operate from a stronger posture at Douglas, the office of the Resident Manager was strengthened, and a new person was brought in for the job. James said that over 90 applications for the position had been received, and he was pleased to report that "a very strong individual" had been chosen. In fact, the successful applicant was so eager to shoulder the responsibilities that he took a salary cut of $8500. "I think we have found just the man we are looking for in order to give us the strength on the spot that we need," James concluded.42
The policy of contractor penetration did not imply relentless meddling in the internal affairs or organization of the company. Indeed, most of the pressure applied by MSFC seemed to occur early in the program. Monitoring continued, but on a lesser scale. The initial problems were peculiar to the complicated requirements of getting "cranked up" for a new program such as S-IVB battleship testing, where MSFC, Douglas, and Rocketdyne (the engine contractor) were all involved. MSFC formulated a "start team" that used personnel from all three organizations. This special group coordinated and channeled early activities, and proved to be a successful approach in the S-IVB program. As the, program gained momentum, the contractor assumed more responsibility. "We also recognized in the S-IVB program that Douglas is a major manufacturing organization and once they get rolling, they are a good organization," said James emphatically. "Our problem always is on the initial stages. We have made a major effort to concentrate on getting the first stage out the door, knowing we can trust a contractor like Douglas to follow on with the succeeding stages."43
The technique of contractor penetration to maintain high visibility obviously generated some thorny issues in government-contractor relations. Nevertheless, MSFC felt that industry had a strong inclination to take control of the job and the funding and pursue the job with a minimum of government intervention. MSFC management believed this inclination allowed too much opportunity for slippage, unidentified [281] problems, and poor communications. Vigorous contractor penetration reduced these program difficulties; in the long run, the contractors seemed inclined to accept the penetration as a mutually useful aspect of completing a successful program. "The restiveness that stemmed from such close control was gradually dissipated very early in the Apollo program as the benefit accruing from the industry-government team approach was revealed," concluded Eberhard Rees.44
Realizing the relationship between contractor motivation and success, the Saturn V Program Office implemented general NASA policy regarding contract incentives as a means of encouraging the contractor to perform at the highest possible level of endeavor. Most of the original contracts stipulated a cost-plus-fixed fee, useful in the early phases of a program when management had to deal with many unknown factors and close pricing was uncertain. After the R&D phase was well in hand and the unknowns were worked out, it became possible to adapt incentive- or award-fee provisions in all Saturn contracts except the S-II stage contract. The S-II contract eventually had limited award-fee provisions for management performance. The contracts for the lunar roving vehicle and the instrument unit were cost-plus-incentive fee (CPIF) from their initiation. The remaining contracts were changed in 1966 from cost-plus-fixed fee to cost-plus-incentive fee.
The incentive contracts were established in two portions: a comparatively modest base fee, and a segment of payments scaled to incentives. These scaled incentive fees were awarded in proportion to the contractor's success in meeting time schedules, cost allowances, and performance ranges. The incentive fee contract was judged to be most successful in cases involving hardware contracts where schedules, costs, and major milestones were fairly well established. The Saturn V Program Office considered the approach a successful alternative to fixed-fee contracts, because the incentive-fee contracts encouraged the contractor to meet commitments on hardware delivery and contributed to mission success.45
Within the Saturn V Program Office, as in other MSFC operations, management paid special attention to the areas of reliability and quality control. The project offices viewed reliability as a significant element of basic design technique, and continued relevant procedures for judging the design of subsystems, components, and parts, as well as the overall stage design. This approach included techniques to evaluate the necessity for redundancy, criticality of numbers, and failure mode and effects analysis. Management also pursued an exceedingly active qualification test program, exposing components and subsystems to simulated flight loads under environmental conditions. This test was a major [282] contributive factor to the success of the Apollo-Saturn program, although it was expensive. The hardware was costly, and rigorous testing of such a large portion of it meant that much of the hardware could not be used later as flight hardware. In some cases where funds were particularly tight, qualification tests were conducted at a reduced level, followed by intensive and exhaustive data analyses to extrapolate performance through various conditions of flight. The object was to be able to use such hardware on actual missions later on. In these instances, it was necessary to be careful not to overstress these future flight components, and to extrapolate data so as to avoid risks during the actual missions.46
The problem of quality control was further affected by MSFC's reliance on the Department of Defense, which exercised quality control management in some of the contractor plants. In the mid- 1960s, MSFC made an effort to increase its own quality control programs, particularly in the inspection of incoming vendor surveillance. Douglas, for example, evolved its own approved parts list; parts not listed were unacceptable in design specifications submitted by prospective vendors. Basic guidelines for the list came from MSFC documents, buttressed by information from the military, industry sources, and Douglas's own experience, and were substantiated by operational and test data in the course of the program. The approved parts list included such items as bearings, fasteners, switches, relays, transformers, wires and cables, capacitors, resistors, semiconductors, and fluid fittings. Among the tangle of parts required to make a rocket work, the pipes and tubing with their respective connections were expected to operate under extreme and rapid temperature change, shocks, low pressure, and intense vibration. All parts had to be flight weight and have the imprimatur of the approved parts list.47
The Saturn V Program Office continued to monitor the activities of its own prime contractors, stepping in when necessary to advise changes. One such instance occurred in July 1964, when one of the welds of the S-IVB stage failed and the consequent rupture of the tankage caused the loss of the entire structural test stage. As a result of this incident, MSFC "caused Douglas to go into TIG welding with the higher heat input than the MIG welding that they were using in certain areas." MSFC technical personnel reported higher reliability after the change, and approved Douglas's revision of weld inspection procedures, which MSFC judged to have been somewhat weak.48
In pursuing reliability and quality control, the project managers found that they had to exercise considerable diplomatic tact, making sure that the contractor had sufficient leeway to develop valid design concepts without overdoing it. "It is in the nature of experts that they become beguiled by intriguing technological problems," warned Eberhard Rees, and such beguilement could lead to excessive pursuit of reliability and performance. This situation was sometimes tolerable in industry, in the interest of better products for competition, but not in the space program. [283] It was necessary to be constantly on guard against losing simplicity-easy to do in the early stages of a program that was complex, large, and pressed by tight schedules. "Even when weighed in the balance against sacrifice of performance, design simplicity should be strongly favored," Rees recommended, because more components and higher performance often increased the prospects for failure. Rees noted that "Project management has here a rather complicated task of putting the brakes on these tendencies without discouraging development of new technology and with it of highly inventive people." Arthur Rudolph was adamant about this point, and put it even more succinctly: "Make it simple, make it simple, make it simple!"49
In the quest for high performance, reliability, and quality control, incentive contracts constituted only one of a number of blandishments. Several techniques were employed by MSFC, including cash awards and special recognition for quality control, cost reduction, and other activities. At MSFC, the Saturn V Program Office cooperated with the Manned Flight Awareness Office in a program to inform and remind all workers in the Apollo-Saturn program about the importance of their work and the need for individual efforts. By means of awards and recognition programs, the Manned Flight Awareness concept became an effective incentive technique. The prime contractors also conducted special incentive programs, in collaboration with the project managers and RMO personnel. North American's program was known as PRIDE (Personal Responsibility in Daily Effort), and Douglas had its "V.I.P." campaign (Value in Performance). MSFC's Manned Flight Awareness personnel and the contractors also participated in a program to make sure that vendors and subcontractors shipped critical spare hardware in special containers and boxes. These boxes were marked with stickers and placards imprinted with reminders to handle with particular care, because the hardware was important to the astronauts whose lives depended on the integrity of the hardware.50
The Saturn V Program Office relied on a facility known as the Program Control Center as a focus for decision-making. The nature of the Saturn program, with contractors and NASA facilities scattered from coast to coast, presented a real challenge in codifying information for managerial decisions. As one Saturn V Program Office manager said, it was "essential that we had some way of making sure that we had pulled together all the facets of the program into an integrated program with good visibility. And that, I would say, has been probably the main purpose of this Program Control Center-to try to provide the program manager with that integrated visibility."51
[284] The archetype of the Program Control Center was probably the "Management Center," developed in 1956 for the use of Rear Admiral William F. Raborn, Jr., during the Polaris program. To get ideas for Raborn's Management Center room, his personnel visited the Air Force Ballistic Missile Division in Inglewood, California, and, interestingly, the ABMA operation in Huntsville. The Polaris center was designed to avoid the look of a boardroom and was filled with 90 chairs facing a large motion-picture and slide screen in the front, and numerous charts hung on the walls around the room. The idea was to provide maximum visual capability of Polaris events in a briefing room.52 The Boeing Company elaborated this concept as a management tool during its Minuteman missile program for the Air Force. Beginning in 1959, a series of Boeing control rooms resulted in a style of visual presentations, by means of charts and audio-visual aids, intended to reduce the reams of management reports being used to monitor the progress of the program. The company activated such a control room at its S-IC (the Saturn V first stage) manufacturing facility at Michoud, near New Orleans, Louisiana, in 1964. In 1965, Boeing was awarded a contract by MSFC to develop an advanced control room management facility at Huntsville.53 This became the Program Control Center (PCC) of Rudolph's Saturn V Program Office. Although the Marshall center's PCC looked somewhat like a boardroom, it became an unusually active facility. The conference table in the center of the room seated 14, and the movable chairs around the edges of the room raised its capacity to several dozen.
The PCC epitomized the managerial concepts of "management by exception" and "single threading." The technique of management by exception was based on the premise that the program manager should keep his number of contacts within manageable limits, and Arthur Rudolph relied heavily on his project managers to work with the contractors and solve various problems as they arose. "Within my Saturn V Program Office," Rudolph explained, "each project manager has wide latitude to exercise management actions just as long as these actions meet established technical performance requirements and schedule and budget constraints." Rudolph's control over the project managers went just far enough to ensure that performance, schedule, and budget guidelines were met, that interfaces were kept in repair, and that unintended redundancy was eliminated. "This policy of management by exception has enabled us to operate effectively and efficiently and has given my people the incentive to perform to their fullest capabilities," he said.54
The PCC needed to develop a means of singling out special problems for more detailed analysis, including probable program impact, and to know exactly who was responsible for monitoring and solving problems. The concept of "single threading" provided graphic documentation for tracing a problem to a detailed position for assessment and determining a probable course of action to resolve it.55 The means for [285] such analysis were embodied in the data organized for viewing in the PCC. Thus, the PCC was an arena for comprehensive displays for use by management-a focal point for collection and presentation of information concerning the status of the Saturn V program, and planned so as to provide displays for various levels of detail. This approach permitted managers to identify the problem, begin action for resolution, and monitor progress.
The PCC for the Saturn V Program Office was one of a network of such rooms located in the Apollo Program Director's office at Headquarters, at each of the three Apollo-Saturn NASA centers (Kennedy, Marshall, and Houston), at each of the prime contractors' offices, and at Mississippi Test Facility. The network allowed top management and other personnel to keep up with a myriad of activities, including logistics, astronaut training, scientific projects, selection of lunar landing sites, the worldwide tracking network, mission planning, and the mission itself. Each had the latest information and up-to-date displays for its appropriate job, including general Apollo-Saturn program information as required, along with a sophisticated communications system to accelerate the decision-making process.56
The PCC provided two basic ways to display information: open wall displays and projected visual aids. The open wall displays were used to portray information that was updated and changed on a cyclical, day-to-day, or new-problem basis. Most of the display charts were constructed so that they could be moved in and out of position on horizontal tracks. They were marked by coded symbols so the viewer could tell at a glance if a project was lagging, ahead of schedule, or on schedule. Both the project offices and the staff-functional offices submitted data and maintained liaison with PCC personnel throughout the preparation and use of the display charts, and the offices were responsible for having proper attendance in meetings where their display material was to be discussed.
Each display carried the name of the individual responsible for the data. If the project office representative could not answer questions or supply additional information, the person to contact was immediately identifiable from the chart, and a quick phone call could make him-or the information-available during the meeting. Some charts concerned items being covered by what MSFC called the problem resolution system. The data indicated the criticality of the problem, the specific hardware or operation involved, the originator of the data, the identity of the "action manager," and the current status of the problem. Other charts showed aspects such as costs and technical data (weight, performance, and configuration management).
Rudolph always insisted on having a name associated with the charts. He wanted to work with a person, he said, not an anonymous office. Backing up the charts was a comprehensive set of "management matrices" in notebooks, listing all individual counterparts, by name, for all....
.....major systems and subsystems of the hardware. The matrix pages included MSFC counterparts for Industrial Operations and R&DO, other centers, and the contractors. To find out why a valve did not work, the Saturn V Program Office could call each person responsible for the project, and not waste time calling the wrong office or waiting for an office manager to decide who could provide a competent response to a specific query.57 Rudolph wanted a fast and accurate response to problems, and he usually got it.
For a long time, the rear of the PCC was dominated by a huge PERT chart (Performance, Evaluation, and Reporting Technique). PERT was a sophisticated and complex computerized system, with inputs beginning, literally, at the tool bench. Technicians on the floors of contractor plants around the country monitored the progress of nearly all the hardware items and translated the work into computer cards and tapes. Data for costs and schedules were also entered into the system. The PERT network was broken down into 800 major entities, and summarized 90 000 key events taking place around the country. PERT helped provide [287] the answers. If a gas generator exhaust line under test in California was showing problems, how would this affect the static test schedule at the Mississippi Test Facility (MTF), and a scheduled launch from Cape Kennedy? What would be its cost impact? How would it affect other hardware? What would be done about it?58
Like the PCC network, PERT received a strong impetus in the Polaris program in the mid-1950s.59 During the early phases of the Saturn program, MSFC management regarded PERT as a very successful effort. At a NASA Management Advisory Committee conference in 1964, von Braun said that PERT was the best source of information available on the status of hardware programs. The PERT network did not catch everything; for example, a parts problem on Boeing's S-IC-T (test stage) had been missed. Still, MSFC managers in 1973 recalled PERT as one of the most useful management systems, although the PERT network was phased out about the time of the launch of the first Saturn vehicle (AS-501) in the winter of 1967. One reason was that PERT was tremendously expensive. A large number of people within NASA and from the contractor's special computer programs were needed to make the network perform adequately. "It has some use as a preliminary planning tool," said R. G. Smith, a Rudolph successor, "but when tens of thousands of events per stage are used, it is difficult to analyze, usually lagging in real time usefulness, and subject to manipulation to avoid exposure of real problems."60
During launch operations and special activities, the PCC was linked to KSC and Houston by closed-circuit television. Although conferences in the PCC were not televised by closed circuit (because of space limitations and technical problems), the communications arrangement permitted discussions in the PCC to be heard instantaneously at NASA Headquarters and other centers. The ceiling of the PCC room was studded with extrasensitive microphones, so that anyone at the conference table in Huntsville could interject a comment or respond without leaving his seat, and nobody had to wait until a speaker somewhere else had finished. When a speaker in Huntsville was making a presentation, conferees in Houston or Cape Kennedy could freely respond. In addition, conferees visually followed the presentation at other locations by means of viewgraphs supplied beforehand by the speaker. The viewgraphs were transmitted by Long Distance Xerox (LDX) system on a leased telephone circuit. Using standard typewriter-size sheets, the LDX line transmitted high-fidelity copies at the rate of about two copies per minute. After receipt at the other end, personnel used them to reproduce the numbered viewgraphs, shown in sequence as requested by the speaker. The fast response of the LDX system permitted up-to-the-minute documentation, and if there was not time to prepare new viewgraphs, conferees at the other locations could be supplied with regular Xerox copies instead. The ability to exchange such material meant that informed decisions could be made [288] while the meeting was in progress. Rudolph insisted on detailed viewgraphs, in words as well as diagrams, so that the viewgraphs could serve as minutes of the PCC conferences.61
The Saturn V program, and the vehicle itself, was enormously complex. Counting everything from nuts, bolts, and washers to transistors and circuit boards, the Saturn V booster alone had something like 3 000 000 parts (in addition, the command and service modules had 2 000 000 parts; the lunar module 1 000 000).62 Manufacture of the rocket stages involved thousands of contractors and the expenditure of millions of dollars per week. The scope and cost of the effort raised the obvious question: how did NASA do the job? and, more specifically, how did MSFC keep tabs on a multimillion-piece monster? Another question was: is it possible to point to a unique style of management in the lunar landing program?
James Webb, NASA Administrator from 1961 to 1968, warned that in large-scale endeavors such as the Apollo-Saturn program, managers needed to be especially flexible because many "unpredictable difficulties" as well as many "unanticipated opportunities" would crop up. Many traditional management concepts were not applicable because the large-scale R&D endeavor was so dynamic. Managers needed to have a sound foundation in basic management principles, but also needed to be able to work in an environment where the lines of communication crisscrossed and moved in unusual directions, and where the job was not always exactly defined in the beginning. The successful manager had to do more than understand the organizational framework backward and forward. He had to grasp the total dimensions of the effort and define his role in the task. In this context, successful aerospace managers availed themselves of existing fundamentals of management, whatever their source of origin, and raised them to a higher degree of refinement in complex activities involving high technology.63 One sophisticated observer characterized NASA's managerial contributions:
In the Saturn program, successful management style was a blend of the decades of experience of the original von Braun team in Germany and management concepts from the Army, Navy, Air Force, other government agencies, and private industry. As the early SSO began to elaborate its relationships with prime contractors, Air Force concepts of configuration management became more conspicuous. During the evolution of the Saturn program at MSFC, the Army's arsenal concept was inherent in the R&DO arrangement, although its premier role was altered as a result of 1963 reorganization. Both the Army and the Air Force contributed key managers.
The Air Force influence was pervasive, from the Headquarters level on down. George Mueller, Associate Administrator for Manned Space Flight, came from private industry (Space Technology Laboratories), but he had worked with several Air Force missile programs, including Atlas, Thor, Titan, and Minuteman. His deputy for the Apollo-Saturn program, Brigadier General Samuel C. Phillips (USAF), brought skills in configuration management and logistics management that had been acquired during the Minuteman effort. At MSFC, Robert Young, the first IO director, had executive experience with an industrial contractor (Aerojet) that also had been involved in Air Force missile programs. Young was succeeded by General Edmund F. O'Connor (USAF). The influx of other Air Force officers in 1964 has already been noted. On the other hand, numerous Army officers left ABMA to join MSFC, including Lee James, who served at one time as the Saturn I-IB Program Manager, worked at NASA Headquarters, and later was head of the IO division. James replaced General O'Connor, who had returned to the Air Force. From NASA Headquarters, Mueller's GEM Boxes constituted a significant managerial technique in the Apollo-Saturn program, and MSFC elaborated upon its own concepts of working groups, management matrices, and (borrowing a bit from the Polaris program) the Program Control Center.65
From his vantage point as an active manager in the Army and NASA and as an observer of Air Force management, Lee James paid special tribute to the R&DO laboratories that he believed gave MSFC "unusual depth." The laboratories were one of the outstanding aspects of MSFC management under von Braun. "It's hard to make them work in the government," James said. "That is a unique attribute."66 Although von Braun emphasized the overriding authority of the program and project offices in their relationships with the laboratories,67 contacts were not always unruffled. During a session with Headquarters executives in 1964, both Rees and von Braun agreed, "The project manager is definitely in [290] the driver's seat on project management matters. R&DO provides technical knowledge in depth to solve the technical problems, but at the same time carefully avoiding any interference with contract management. The stage manager is the sole contact with the contractor." Reading the minutes of the meeting a few days later, one of the top managers in the Saturn V Program Office expressed his frustrations in an astringent comment scribbled in the margin: "Wouldn't it be good if this were so! Top mgt. needs to say so in a policy statement and then enforce it."68 The situation festered for several months, until von Braun issued a detailed directive to the heads of both Industrial Operations and R&DO, in which the authority of Industrial Operations (and the Saturn V Program Office) was asserted in explicit terms.69
Although it is difficult to document the specifics, relationships between Industrial Operations and R&DO were often uneasy. As recalled by an observer from within the Saturn v Program Office, one form of managerial assertion was out-and-out harassment. A stage manager might call up a laboratory chief in R&DO and complain about the lack of activity or lack of cooperation from the counterpart personnel in the laboratories. Other methods included pointed reminders about directives from the program manager's office, a claim to be acting at the behest of the program manager, the use of technical knowledge that others would hesitate to contradict, and outright exposure of deficiencies.70
The same techniques were also applied within the Saturn V Program Office, as the staff-functional managers (the GEM Boxes) jousted with the stage managers. It must be remembered that Rudolph considered his functional managers to have as much authority as his stage managers. This approach was unique to the Saturn V Program Office; other program offices tended to allow the hardware managers greater authority. Rudolph's arrangement was deemed necessary, however, to maintain vertical control over the stage elements of the Saturn V, especially since the stage managers were sometimes considered to manifest a parochial attitude about their own activities.71 The role of the functional managers was spelled out in a program element plan document:72
The Saturn management concept consistently put a premium on visibility, epitomized by the Program Control Center in the Saturn V Program Office. Webb, who prided himself in the development and exercise of managerial expertise, was amazed by its conceptual format [291] and versatility. During a visit to MSFC in 1965, not long after the activation of the PCC, Webb was given a thorough briefing on the facility by Rudolph and Bill Sneed, who was head of the Program Control Office at the time. Following the briefing, Webb addressed a select group of MSFC personnel, and was obviously enthusiastic about the PCC concept. "I saw here in the hour before you arrived," he exclaimed to his audience, "one of the most sophisticated forms of organized human effort that I have ever seen anywhere."73 Webb's remark was a special compliment to Huntsville's PCC; Huntsville later became the model for NASA's Apollo Program Office in Washington as well as for other centers and prime contractors. Over a period of years, at Webb's behest, a stream of executives from government and American and foreign industry trouped through the PCC. The Saturn V Program Office also received inquiries by telephone and letter from a wide spectrum of sources, including the famed design group of Raymond Loewy and Associates. A former member of the Polaris management team once visited the PCC and came away thoroughly impressed. "This chart room of yours is an amazing place," he said to Rudolph. "I used to think the ones we had in the Polaris program were good, but this puts us to shame."74
The Marshall center's organization experienced several adjustments after 1969 in response to new directions in NASA programs. By 1972, the IO segments operated as individual program offices and reported directly to the head of the center. The R&DO laboratories were set up as the Directorate of Science and Engineering, along with several other directorate organizations. Under the new scheme, the Saturn Program Office contained all the various stage and engine offices for the Saturn IB and Saturn V, and also included the PCC. Many of the individuals associated with the original Saturn V Program Office took new positions involving Skylab, the Space Shuttle, and other projects. Following the Apollo-Soyuz Test Project in August 1975, NASA planned no more launches of the Saturn class of vehicles, and the Saturn Program Office was finally dissolved.
MSFC management strongly reflected the tradition of the "dirty hands" approach begun by the von Braun team at Peenemuende and continued during the operations at ABMA. The organizational structure and influence of the technical laboratories was another vestige of rocketry work from the pre-World-War-II era. The pronounced shift toward managerial functions after the 1963 NASA-MSFC reorganization enhanced the prestige of Marshall's Industrial Operations component, and the influence of Air Force concepts of missile management was [292] evident in the extended tenure of General Edmund F. O'Connor as its head.
The crux of Saturn V management was Arthur Rudolph's Saturn V Program Office. Rudolph's missile management skills had been enhanced by the Redstone and Pershing programs; as a Peenemuende veteran, he could also relate effectively to von Braun and other key MSFC managers of similar backgrounds. Within Rudolph's organization, the "GEM Boxes" provided an effective and crucial link to offices at NASA Headquarters and developed and applied various management systems serving Marshall and the contractor; the Program Control Center provided the means for visibility and accountability in the Saturn program.
It is impossible to pinpoint any single outstanding or unique management concept that led the program to success. The NASA-MSFC "style" seems to be more of an amalgam of various concepts, although these concepts were refined for the unique scope and complexity of the Saturn program. In general, the government- industry partnership was notably successful, and the in-house capability at MSFC was highly effective in monitoring contractor performance and providing backup skills and facilities. The organization and operation exhibited by the Program Control Center lent a theme of "visibility" to the Saturn program. Among the many managerial tasks, logistics was a major effort.


I'm a recently graduated student from the University of Hawaii at Manoa. I graduated with a B.S. in Computer Science! When I am not working on websites, I spend my time working on a flower farm, playing video games, and enjoying food. Previously, I was the web designer for the UH Manoa Insect Museum and Rubinoff Lab, check them out below!
.


Triggers in sequence, an output of three integers, each within their own context.
module modSequencer <src_file = "sequencr.cxx"> { prim+IPort2 trigger; int+OPort2 seq_1; int+OPort2 seq_2; int+OPort2 seq_3; cxxmethod+req update ( .trigger+notify, .seq_1+write, .seq_2+write, .seq_3+write ); };
Triggers in sequence, an output of three integers, each within their own context. This is basically a series of context push and pops to force Express to trigger in a more controlled manner what parts of a network will fire.
trigger
Input trigger to start the context push and pops. Each output integer is called in turn, each within its own context.
seq_1
Integer output to be used a trigger for a sub-network within the user's application. This integer is called first. Network objects connected to the other output triggers will not be triggered duting this context, thus ensuring that all network objects connected/triggered by this trigger will fire before objects connected to the remaining triggers.
seq_2
Second output trigger to fire a second sub-network of components. When this triggers it can be assumed that all objects connected to the previous trigger will have fired and completed.
seq_3
Third and final trigger. Last set of network components to be fired. Assume that previous two triggers have fired and all objects have updated in the previous two sub-networks.
n/a
n/a
xp_comm_proj/sequencr/seqrmods.v contains the modSequencer module V definition.
The low-level SequencerMods library containing the module modSequencer does not specify a process. By default the express process will be used.
Brian Selle, Leon Thrane, Advanced Visual Systems Inc. Documentation - Ian Curington, Advanced Visual Systems Inc.
Paul G. Lever
n/a


Admin Panel
Client Side
Product List
Product No
Product Name
Product Price
Action
Order List
Order No
Product Name
Product Price
Agent
Action


BSc Engg in Telecomm Engg at BIT,Khulna March 2006 ~ February 2007
BSc in Beng, Eng, M, Phy & Mil Subj BMA Bhatiary,Ctg August 2000 ~ July 2003
PUBLICATIONS
Performance Analysis of a MC-DS-CDMA wireless comm with Rake Receiver under Nakagami-m fading environment at ICEEE, Rajshahi, Bangladesh 04,Nov 2015 ~ 06,Nov 2015


Hello, Welcome to HW-Monster site.
Are you ready to join HW-Monster site? Please click 'START'..
START


A Appendix A
Solving normal distribution problems is quite easy if you remember some simple items.
A.1 Item 1: Standard Normal Distribution and z-table
Standard normal distribution is special case of normal distribution with mean (\(\mu\)) of 0 and standard deviation (\(\sigma\)) of 1. The cumulative distribution function (CDF) values (\(P(X \le x)\)) of std normal distribution are given in the z-table.
Note: CDF of the standard normal is also denoted with \(\Phi(x) = P(X \le x)\). Note 2: For those of you who did not grasp the concept of CDF; it is basically the probability that the outcome of the event is less than the value specified. For instance \(\Phi(0)\)
A.2 Item 2: Convert and normal process to standard normal.
Suppose you have a process (say, you pour cream on cakes) with mean 50 and standard deviation 5 and you want to know the probability of getting less than 52. Follow this formula.
\[\Phi \left(\dfrac{X-\mu}{\sigma}\right)\]
So in our case, \(\Phi \left(\dfrac{52-50}{5}\right) = \Phi(0.4)\).
A.3 Item 3: How to read z-table.
In the z-table sum of row and column names gives us the value (\(x\)) and their corresponding value gives us the probability \(\Phi(x)\). In our example \(\Phi(0.4) = \Phi(row + column) = \Phi(0.4 + 0.00) = 0.6554\)
The notation for getting the (quantile) value is \(\Phi^{-1}(0.6554) = 0.4\).
A.4 Item 4: Symmetry
The standard normal distribution is symmetric around 0. It gives us the following useful property \(\Phi(-x) = 1 - \Phi(x)\). See \(\Phi(-0.4) = 1 - 0.6554 = 0.3446\).
A.5 Item 5: Understand intervals.
Due to the nature of normal distribution events mainly occur around the mean. That’s why central intervals are given with some probability instead of from the bottom to the end. For instance suppose we would like to know the probability around +-9.8 liters around the mean.
\[P(50 - 9.8 < X < 50 + 9.8) = P(40.2 < X < 59.8) = P(X < 59.8,X > 40,2) = P(X < 59.8) - P(X < 40.2)\]
Convert to standard normal.
\[P(X < (59.8 - 50)/5) - P(X < (40.2 - 50)/5) = \Phi(1.96) - \Phi(-1.96)\]
We know that \(\Phi(-x)= 1 - \Phi(x)\), so \(\Phi(-1.96) = 1 - \Phi(1.96)\).
\[\Phi(1.96) - \Phi(-1.96) = \Phi(1.96) - (1 - \Phi(1.96)) = 2*\Phi(1.96) - 1\]
Check the z-table
\(\Phi(1.96)\) is 0.975. So \(2*0.975 - 1 = 0.95\).
A.6 Item 6: Moving the mean
It is possible to desire an increased level of quality. For instance, if we would like to have 90% of the cakes have at least 50 grams of cream instead of 50 grams just being the mean. So \(P(X > 50) = 1 - P(X < 50) = 0.9\), then \(P(X < 50) = 0.1\). You have the same standard deviation of 5 but you need a new mean.
\[\Phi \left(\dfrac{50 - \mu^*}{5}\right) = 0.1\]
We should invert the standard normal variate \(\Phi^{-1}(0.1)\). Let’s check the z-table for the values corresponding to 0.1.
Well, closest value is 0.1003 so we go with it (usually linear interpolation is done, but we’ll skip that). The corresponding value is -1.28.
\[\begin{align*} \dfrac{50 - \mu^*}{5} &= -1.28 \\ 50 - \mu^* &= -1.28*5 = -6.4 \\ \mu^* &= 50 + 6.4 = 56.4 \\ \end{align*}\]So we should align ourself to pour 56.4 grams of cream per cake on average in order to have 90% of the cakes with 50 grams or more cream.
A.7 Conclusion
By the end of this tutorial you should know your way around the normal distribution problems. It is not hard but you might need some practice till you get adept on the topic.
Walpole, Ronald E., Raymond H. Myers, Sharon L. Myers, and Keying Ye. 2012. Probability and Statistics for Engineers and Scientists. 9th ed. Boston, MA: Pearson.


You've been Juntified!
by
<%=user.FirstName + " " + user.LastName%> invites you to join <%=tab.Name%>
Juntas extension is not installed in your browser.
Add to Chrome
You've been Juntified!
Juntas extension is not installed in your browser. click the button beloow to install it.
Add to Chrome


Enter your string here and click submit to see which characters are most/least frequent.
{{ vm.mostFrequentChar }}
{{ vm.leastFrequentChar }}


s">
ramaiah dawai wale
Home
About
Signup
Login
Ramaiah Dawai Wale
enter the medicine name:
Get Started


|
Elektra
0.8.18
|
Key is an essential class that encapsulates key name , value and metainfo . More...
Modules | |
| Meta Info Manipulation Methods | |
| Methods to do various operations on Key meta data. | |
| Methods for Making Tests | |
| Methods to do various tests on Keys. | |
| Name Manipulation Methods | |
| Methods to do various operations on Key names. | |
| Value Manipulation Methods | |
| Methods to do various operations on Key values. | |
Enumerations | |
| enum | keyswitch_t { KEY_NAME =1, KEY_VALUE =1<<1, KEY_OWNER =1<<2, KEY_COMMENT =1<<3, KEY_BINARY =1<<4, KEY_UID =1<<5, KEY_GID =1<<6, KEY_MODE =1<<7, KEY_ATIME =1<<8, KEY_MTIME =1<<9, KEY_CTIME =1<<10, KEY_SIZE =1<<11, KEY_DIR =1<<14, KEY_META =1<<15, KEY_END =0 } |
| Allows keyNew() to determine which information comes next. More... | |
| enum | elektraNamespace { KEY_NS_NONE =0, KEY_NS_EMPTY =1, KEY_NS_META =2, KEY_NS_CASCADING =3, KEY_NS_FIRST =4, KEY_NS_SPEC =4, KEY_NS_PROC =5, KEY_NS_DIR =6, KEY_NS_USER =7, KEY_NS_SYSTEM =8, KEY_NS_LAST =8 } |
| Elektra currently supported Key namespaces. More... | |
Functions | |
| Key * | keyNew (const char *name,...) |
| A practical way to fully create a Key object in one step. More... | |
| Key * | keyDup (const Key *source) |
| Return a duplicate of a key. More... | |
| int | keyCopy (Key *dest, const Key *source) |
| Copy or Clear a key. More... | |
| int | keyDel (Key *key) |
| A destructor for Key objects. More... | |
| int | keyClear (Key *key) |
| Key Object Cleaner. More... | |
| ssize_t | keyIncRef (Key *key) |
| Increment the viability of a key object. More... | |
| ssize_t | keyDecRef (Key *key) |
| Decrement the viability of a key object. More... | |
| ssize_t | keyGetRef (const Key *key) |
| Return how many references the key has. More... | |
Key is an essential class that encapsulates key name , value and metainfo .
To use it include:
Key properties are:
Key
structure is not defined in kdb.h, only declared. So you can only declare pointers
to Keys
in your program, and allocate and free memory for them with keyNew() and keyDel() respectively.| enum elektraNamespace |
Elektra currently supported Key namespaces.
| Enumerator | |
|---|---|
| KEY_NS_NONE |
no key given as parameter to keyGetNamespace() |
| KEY_NS_EMPTY |
key name was empty, e.g. invalid key name |
| KEY_NS_META |
meta key, i.e. any key name not under other categories |
| KEY_NS_CASCADING |
cascading key, starts with /, abstract name for any of the namespaces below |
| KEY_NS_FIRST |
For iteration over namespaces (first element, inclusive) |
| KEY_NS_SPEC |
spec contains the specification of the other namespaces |
| KEY_NS_PROC |
proc contains process-specific configuration |
| KEY_NS_DIR |
dir contains configuration from a specific directory |
| KEY_NS_USER |
user key in the home directory of the current user |
| KEY_NS_SYSTEM |
system key is shared for a computer system |
| KEY_NS_LAST |
For iteration over namespaces (last element, inclusive) |
| enum keyswitch_t |
Allows keyNew() to determine which information comes next.
| Enumerator | |
|---|---|
| KEY_NAME |
Flag for the key name |
| KEY_VALUE |
Flag for the key data |
| KEY_OWNER |
Flag for the key user domain |
| KEY_COMMENT |
Flag for the key comment |
| KEY_BINARY |
Flag if the key is binary |
| KEY_UID |
Flag for the key UID
|
| KEY_GID |
Flag for the key GID
|
| KEY_MODE |
Flag for the key permissions
|
| KEY_ATIME |
Flag for the key access time
|
| KEY_MTIME |
Flag for the key change time
|
| KEY_CTIME |
Flag for the key status change time
|
| KEY_SIZE |
Flag for maximum size to limit value |
| KEY_DIR |
Flag for the key directories
|
| KEY_META |
Flag for meta data |
| KEY_END |
Used as a parameter terminator to keyNew() |
| int keyClear | ( | Key * | key | ) |
Key Object Cleaner.
Will reset all internal data.
After this call you will receive a fresh key.
The reference counter will stay unmodified.
| returns | 0 on success |
| -1 | on null pointer |
| key | the key object to work with |
| int keyCopy | ( | Key * | dest, |
| const Key * | source | ||
| ) |
Copy or Clear a key.
Most often you may prefer keyDup() which allocates a new key and returns a duplication of another key.
But when you need to copy into an existing key, e.g. because it was passed by a pointer in a function you can do so:
The reference counter will not be changed for both keys. Affiliation to keysets are also not affected.
The meta data will be duplicated for the destination key. So it will not take much additional space, even with lots of metadata.
When you pass a NULL-pointer as source the data of dest will be cleaned completely (except reference counter, see keyClear()) and you get a fresh dest key:
If you want to copy everything, except e.g. the value you can use keyCopy() too:
Restrain from coping everything yourself, because it will lead to wrong metadata and is not able to copy empty or cascading names:
| dest | the key which will be written to |
| source | the key which should be copied or NULL to clean the destination key |
| -1 | on failure when a NULL pointer was passed for dest or a dynamic property could not be written. The content will be unmodified then. |
| 0 | when dest was cleaned |
| 1 | when source was successfully copied |
| ssize_t keyDecRef | ( | Key * | key | ) |
Decrement the viability of a key object.
The references will be decremented for ksPop() or successful calls of ksLookup() with the option KDB_O_POP. It will also be decremented with an following keyDel() in the case that an old key is replaced with another key with the same name.
The reference counter can't be decremented once it reached 0. In that situation nothing will happen and 0 will be returned.
| -1 | on null pointer |
| 0 | when the key is ready to be freed |
| key | the key object to work with |
| int keyDel | ( | Key * | key | ) |
A destructor for Key objects.
Every key created by keyNew() must be deleted with keyDel().
It is save to delete keys which are in a keyset, the number of references will be returned then.
It is save to delete a nullpointer, -1 will be returned then.
It is also save to delete a multiple referenced key, nothing will happen then and the reference counter will be returned.
| key | the key object to delete |
| 0 | when the key was freed |
| -1 | on null pointers |
| Key* keyDup | ( | const Key * | source | ) |
Return a duplicate of a key.
Memory will be allocated as needed for dynamic properties.
The new key will not be member of any KeySet and will start with a new reference counter at 0. A subsequent keyDel() will delete the key.
Like for a new key after keyNew() a subsequent ksAppend() makes a KeySet to take care of the lifecycle of the key.
Duplication of keys should be preferred to keyNew(), because data like owner can be filled with a copy of the key instead of asking the environment. It can also be optimized in the checks, because the keyname is known to be valid.
| source | has to be an initialized source Key |
| 0 | failure or on NULL pointer |
| ssize_t keyGetRef | ( | const Key * | key | ) |
Return how many references the key has.
The reference counting is the essential property of keys to make sure that they can be put safely into data structures. E.g. if you put a Key into a KeySet:
You can even add the key to more KeySets:
If you increment only by one with keyIncRef() the same as said above is valid:
or use keyIncRef() more than once:
The key won't be deleted by a keyDel() as long refcounter is not 0.
The references will be incremented on successful calls to ksAppendKey() or ksAppend().
For your own applications you can use keyIncRef() and keyDecRef() for reference counting, too.
| key | the key object to work with |
| -1 | on null pointer |
| ssize_t keyIncRef | ( | Key * | key | ) |
Increment the viability of a key object.
This function is intended for applications using their own reference counter for key objects. With it you can increment the reference and thus avoid destruction of the object in a subsequent keyDel().
The reference counter can't be incremented once it reached SSIZE_MAX. In that situation nothing will happen and SSIZE_MAX will be returned.
| -1 | on null pointer |
| SSIZE_MAX | when maximum exceeded |
| key | the key object to work with |
| Key* keyNew | ( | const char * | name, |
| ... | |||
| ) |
A practical way to fully create a Key object in one step.
To just get a key object, simple do:
If you want the key object to contain a name, value, comment and other meta info read on.
You can call it in many different ways depending on the attribute tags you pass as parameters. Tags are represented as keyswitch_t values, and tell keyNew() which Key attribute comes next.
We can also give an empty key name and a KEY_END tag with the same effect as before:
But we can also give the key a proper name right from the start:
So, keyNew() allocates memory for a key object and keyDel() cleans everything up.
keyNew() processes the given argument list even further. The Key attribute tags are the following:
keyName
is 0.| name | a valid name to the key, or NULL to get a simple initialized, but really empty, object |
| NULL | on allocation error or if an invalid name was passed (see keySetName()). |


09. Write an expression that checks for given point (x, y) if it is within the circle K( (1,1), 3) and out of the rectangle R(top=1, left=-1, width=6, height=2).
The result is printed on the JS console...


Stock Market Portfolio Simulator
Build A Portfolio & Track Your Results
- This simulator allows you to test out your trading theories in a paper account
- Start out with $100K in paper money
- Hold up to 5 stocks at any given time
- Track your performance over time and view your transaction history


">
Epicodus Week 3 Independent Project
The HALsplainer...
Are you ready, Dave?
Tell me a number you are thinking of, and I will tell you what it
REALLY
means!
Number, please?
Click NOW!!
Well, actually...
I think you meant to say:
Do you need me to explain that again?
Click here
for a reiteration.


Note that the first letter of the answer is ignored in the word play of each clue
Clues:
A. Fair play snaring colony's first big piece of land (6)
B. Perform "End of the Line" and "Brazilian Memoirs" along with one some called "About the Little Things" (15)
C. If I attend, I only ruin discretion (15)
D. Go too slow in Joplin number perhaps (4)
E. Thomas is embraced by Bradman (6)
F. Worked on a mere appellation? (8)
G. Clear pattern of orthogonal lines (4)
H. Ferenc Preisach modelled it without a transform... rest is easy! (10)
I. Overwhelm sister with night out (8)
J. A flat finish? (5)
K. Worked in the kitchen with requirement to receive notice (7)
L. Buttering mash, one's heart's not in it and one drops bits on the ground (9)
M. Fun to give incorrect data: I'm roughly ten (9)
N. Roam around with Jean perhaps (5)
O. Not having one limits food intake for man of dramas (5)
P. Money handed out in one's confused state (7)
Q. You finally got creative work with end of jazz-rock (6)
R. Restating arrangements for someone who's on the list (10)
S. For jazzy feel, improvise (5)
T. Dashed to catch the one thing that people dash to catch (5)
U. Ben's luck rotten... gets free of belt (9)
V. Russian leader laid out by Russian craft (8)
W. Note nasty bug (6)
X. Coming up... 0:54 (5)
Y. Northern country, or hiker's fantasy (9)
Z. Bank one obstacle to part of (A) (8)


This page contains a collection of examples for various C3 visualizations.
They start with simple tables and static plots and build to more complex examples
with multiple linked vizualizations of multivariate datasets.
Click on the example names in the left navigation pane to view the example.
The HTML and annotated source code for each example is also hosted for viewing.
The examples are written in TypeScript
which, for these examples, should basically look like JavaScript with some occasional type annotations.
A full c3.d.ts
type definition file is provided for those wishing to use TypeScript, however
JavaScript, CoffeeScript, or any other compatible language may be used.
The only dependencies used by these examples are D3, and some examples may also
include jQuery, Crossfilter, and an ES6 Promises polyfill.
Back to C3 Documentation.
API Overview
API Documentation


Your result was Canada! America's hat! With the world's richest supply of beaver pelts and maple syrup our friendly neighbor to the north is always welcoming to tourists looking to enjoy their beautiful country. According to our sophisticated personality test you're almost Canadian yourself so I'm sure you'll feel at home.
Your result was China! Ni hao, Asia! Get ready to delve into one of the worlds richest and oldest cultures. There's no end to discovery. They may even let you pet a panda!
Your result was England! This former colonial powerhouse is home to some of the finest boiled cuisine the world has ever known. Grab your bowler hat and cane and hop on a doubledecker bus bound for adventure! You're sure to fit right in! Based on our sophisticated algorithms we ran on your survey questions you're practically related to the Queen!
Your result was Germany! Grab your lederhosen and get ready to party! Perhaps best known for inventing sausage and the accordian, but Germany is also the worlds leading producer of industrial music dance clubs. Feel free to gloss over the darkest chapter in western history as you enjoy the many sights this fine country has to offer! Auf wiedersehen, boredom! Guten tag, adventure!
Your result was Mexico!  You're sure to fit right in! Based on our sophisticated algorithm we ran on your survey result you're practically a native. Next stop adventure!


Paste DPControl from
visual6502.org
Map It
Paste
phi1
phi2
Block Diagram of 6502 MIcorprocessor, Circa 1979
Drawing © 1995-2011 Donald F. Hanson


Rebuild the search index (*.pdx) that is used by Adobe Reader to perform fast multi-documents search.
Notes: - This task relies on Adobe Acrobat to rebuild the search index. You must ensure a valid
installation of Acrobat is present and that it includes the Catalog module (only available in the PRO suites on
the latest versions released by Adobe).
- This task doesn't create the search index. The (empty) search index must be first created in Adobe Acrobat and
may then be updated using this task when the referenced PDFs have changed.
| Attribute | Description | Required |
| index | The search index file (*.pdx) to rebuild. | Yes |
| startdelay | The delay (in seconds) to wait for Acrobat to start. | No, Defaults to 5 seconds. |
| logerrormatch | The regular expression the last line of Acrobat's log file should match to let BibAnt detect an error occurred while rebuilding the index. This attribute is mainly provided to support other locals than English-US/UK, in which case the error message output by Acrobat in its log file may differ. | No, Defaults to .+\WErr.+ to match English-US/UK locals. |
| keeplog | Option to keep the log file generated by Acrobat while building the search index. | No, Defaults to false |
The following example rebuild the index.pdx
index file:
<rebuildindex index="index.pdx" />


I'm going to Las Vegas this week for a work sponsored developer's convention, therefore, I do not expect to post this week. As an early treat, here is another YWAP video.
This video is of YWAP Camp. This will also feature faces from Highland Baptist, because camp occurred on the last weekend of that team's trip.
This summer's camp was highly successful and ministered to 200 students. Much credit should be given to the missionaries and the rest of the YWAP staff (and many YWAP parents) for all the administrative, musical, recreational, teaching and prayerful effort they put into making the camp happen.
The theme of camp was "Aliens" as the opening song (by Lecrae) signifies.
Also, I will be getting married in 7 weeks. Whoop!


This paragraph is extra small.
This paragraph is small.
This paragraph is medium.
This paragraph is large.
This paragraph is extra large.
< back


The goal here is to visualize the waveform and spectra from web audio api oscillators -- sine, square, sawtooth and triangle -- at 440 Hz.


This script updates all maven jobs having a deploy goal by install and activate the post build step to deploy artifacts at the end of the build
The script also overrides the parameter of the job to ensure you are archiving the artifacts (this is mandatory by the post build task).
import java.util.* import hudson.model.* import hudson.maven.* import hudson.maven.reporters.* import hudson.matrix.* import hudson.tasks.* hudson.model.Hudson.instance.items.findAll{job -> job.isBuildable() && job instanceof MavenModuleSet}.each { job -> println(job.name) if (job.goals.indexOf("deploy")>0) { println("* Must update goals (deploy -> install) : " + job.goals) def newGoals = job.goals.replaceAll("deploy", "install"); println("* New goals : " + newGoals) // Comment the 3 following lines for a first run to check goals modifications without modifying anything job.goals = newGoals job.archivingDisabled = false // It is necessary to archive artifacts to deploy them after the build job.publishers.replace(new hudson.maven.RedeployPublisher(null, null, true, false)); println("* Redeploy publisher added"); } else { println("* This maven job doesn't deploy its artifacts"); } }


DSPK V04.00 Furcadia // Create helper functions function animate(array) { // Dragonspeak easily mixes in with javascript. for (var i = array.length-1; i > 0; i--) { (5:5) change object type `array[i-1]` to type `array[i]`. } } (0:100) When 1 seconds have passed, offset by 0, animate([1,2,3,4,5]); animate([6,7,8,9,10]); // You can reference javascript objects easily var randomObject = 1000; (0:19) When somebody uses object type `randomObject`, (3:5) where the triggering furre was at, (5:4) place object type `randomObject + 1`. // Loop code several times for (var i = 0; i < 10; i ++) { (0:100) When 1 seconds have passed, offset by 0, (1:30) and the floor at (%object_`i`) is the same as the floor at (2,9), (5:302) take variable %inventory_`i` and add 1 to it. } *Endtriggers* 8888 *Endtriggers*
Compile


Please sign up
Fill out the form to get started.
Signup
Have an account?
Signin
OR
Signup with Facebook
Signup with Twitter


{% extends "yaba/layouts/base.html" %} {% block title %}About | {{ block.super }}{% endblock %} {% block main_content %}
I'm a full stack web developer and software engineer based in the city of Chihuahua, located in the northern region of México. I have a B.A. degree in Computer Information Systems from the Univeristy of Texas at El Paso (UTEP), where I graduated with honors in 2012.
My favorite web development tools are Django and Node.JS for the backend and React.JS and Webpack for the frontend, but I can work with most MVC-oriented architectures/frameworks based on Python, Node.JS or PHP, as well as with most modern Javascript frontend tools. I also have 3 years of experience working with Wordpress CMS (developing custom themes and plugins) and I have a very solid understanding of SEO principles.
{% endblock %}