What are the differences between hardware and software security?

To use a simple explanation, making hardware secure consists of doubling up with backup machines. The “high availability” market developed to meet this need. The reasoning behind making software secure is different because the challenge is to maintain a certain level of stability in a context of continuous change. Software security draws on long-proven software quality methods that also apply to internal developments. In particular, these methods plan for definition of a number of work environments in order to establish processes to validate new versions.
The next step is to define the processes to make these new versions available to users--also called transfer to production. How can you make transfer to production secure? First off, by automating the procedure. The difficulty is to obtain 100% automation. The challenge is even greater when we consider that a transfer to production does not simply consist of moving software components into a target environment. We must also consider database upgrades, data retrieval, configuration table updating, non-degradation of local configurations, respect for security, etc. All of these factors must be handled in what will almost certainly be a multi-platform environment. Clearly, this is a complex process.

ARCAD’s solution for 100% automation is based on our internal macro-language: Macromaker. Thanks to this language’s power and flexibility, we can take into account all of a client’s specific needs, whether they are related to an organization or to the particular technical characteristics of the processed components. For example, many clients currently have output management tools. These tools generate components linked to native System i components that must be deployed at the same time. This type of special characteristic can be covered simply by adding certain sequences into the standard processes that are delivered with the product.

Since Macromaker is a language, we can add logic to the process. For example, we can ask users questions to orient the process towards a specific processing logic. The system can be configured endlessly. Any particular client request can be processed by adding new parameters.

What is the purpose of automating the development phase if deployment of components in production is not automated and made secure?

Information Technology centers are confronted with problems generated by manual tasks, causing a break in Quality processes. This article discusses some of the technical difficulties you may be confronted with--all of them covered by the ARCAD solutions.

To deal with integrated management of compilation of logicals, the ARCAD distribution macro has a “Send LF source code” parameter. As the name indicates, the parameter lets you send out the source code for Logical Files, then automatically recompile on local machines.

Do you need to customize the installation process for a specific version? Each ARCAD version has its own installation macro that lets it execute specific post-deployment procedures. An example: to execute a data retrieval program for a file after deployment, you can use a standard variable to find the name of the installation library and the file name in an archive library (ARRPLOBJ), then call the retrieval program.

The ARCAD-Skipper deployment module centralizes the launch and flow of your deployment tasks. If a process is waiting for a message, the display turns red and the “5=Display” option in the log gives the job’s complete name. “13=Joblog” displays the local or remote job log. All the environments affected by the installation are visible on the console. When there is an erroneous stop to environment installation, you can re-launch the operation as a unit or decide to roll back (option 11=Rollback) if the distribution rollback type is *MANUAL. Rollback is also possible after a completed deployment (option 99=Rollback, on the Delivery Management screen WRKDLV).

Why does the DSPTFRLOG command contain a SYSNAME parameter? Because the log for transports performed on remote machines is automatically put back on the development machine. The objective is to facilitate searches as needed.

Does your PC application use a DB2 database? Do you have API programs on your System i? On your ARCAD version, you will have heterogeneous components. Deployment will provide synchronous updating of your System i production environment and your Linux (or Windows) server. How?

The TFROBJ command manages native components as well as components in Windows, Unix, or Linux. To declare target directories on the Server, use the WRKENVIFS command.

ARCAD does not accept /QNTC/Server/directory style directories, so create a link with the ADDLNK command.

Automating deployment to a DBCS (Double Byte Character Set): Source code for the components to be is transferred into a buffer library. A list is used to save object locations.

Upon reception, they are modified using a small RPGLE program to change certain field types to “O” (Open). Components are then compiled in the buffer library and the objects are stamped with the initial location saved in the list. Installation then proceeds as usual.

News for 2007!

Our first New Year’s resolution for 2007 is reinforcement of our international position.

As the year begins, we have no fewer than six subsidiaries throughout the world (Annecy, Nashua, London, Madrid, Milan and Friedrichshafen). We will soon be opening a seventh in Luxembourg.

To celebrate this major step in our company’s development, we are proud to offer you a new, more attractive, and more functional Web site. You can find all the latest on our products as well as information on our services and our company. System i platform news is now online as well (ITIL, SOA, system modernization, and more). Come visit us and let us know what you think.

Following the announcement of OSEO ANVAR support dedicated to our ARCAD development project, reaction in the press was swift. The project will expand our solutions to Windows and Unix environments.