---1. Select a,b from abc where abc.state_cd in ${STATE_CD}
2. Select x,y from xyz where xyz.state_cd in ${STATE_CD}
${STATE_CD} is a graph parameter In value - "(IL,CO,MI)"
Problem is ${STATE_CD} is not getting interpreted when I echo the 'Select Statement', hence giving problem.
ans: Anand use eval or export of I table components ...
Or define ${STATE_CD} in ur start script ... thats better...
30. Explain kill() and its possible return values.
There are four possible results from this call:
kill() returns 0. This implies that a process exists with the given PID, and the system would allow you to send signals to it. It is system-dependent whether the process could be a zombie.
kill() returns -1, errno == ESRCH either no process exists with the given PID, or security enhancements are causing the system to deny its existence. (On some systems, the process could be a zombie.)
kill() returns -1, errno == EPERM the system would not allow you to kill the specified process. This means that either the process exists (again, it could be a zombie) or draconian security enhancements are present (e.g. your process is not allowed to send signals to
*anybody*).
kill() returns -1, with some other value of errno you are in trouble! The most-used technique is to assume that success or failure with EPERM implies that the process exists, and any other error implies that it doesn't.
An alternative exists, if you are writing specifically for a system (or all those systems) that provide a /proc filesystem: checking for the existence of /proc/PID may work.
What is the difference between m_rollback and m_cleanup and when would I use them?
Answer
m_rollback has the same effect as an automatic rollback using the jobname.rec file, it rolls back a job to the last completed checkpoint, or to the beginning if the job has not completed any checkpoints. The m_cleanup commands are used when the jobname.rec file doesn't exist and you want to remove temporary files and directories left by failed jobs.
Details
In the course of running a job, the Co>Operating System creates a jobname.rec file in the working directory on the run host.
NOTE: The script takes jobname from the value of the AB_JOB environment variable. If you have not specified a value for AB_JOB, the GDE supplies the filename of the graph as the default value for AB_JOB when it generates the script.
The jobname.rec file contains a set of pointers to the internal job-specific files written by the launcher, some of which the Co>Operating System uses to recover a job after a failure. The Co>Operating System also creates temporary files and directories in various locations. When a job fails, it typically leaves the jobname.rec file, the temporary files and directories, and many of the internal job-specific files on disk. (When a jobs succeeds, these files are automatically removed, so you don't have to worry about them.)
If your job fails, determine the cause and fix the problem. Then:
If desired, restart the job.
If the job succeeds, the jobname.rec file and all the temporary files and directories are cleaned up. Alternatively, run m_rollback -d to clean up the files left behind by the failed job.
What value should I set for the max-core parameter?
Short answer
The max-core parameter is found in the SORT, JOIN, and ROLLUP components, among others.
There is no single, optimal value for the max-core parameter, because a "good" value depends on your particular graph and the environment where it runs.
Details
The SORT component works in memory, and the ROLLUP and JOIN components have the option to do so. These components have a parameter called max-core, which determines the
maximum amount of memory they will consume per partition before they spill to disk. When the value of max-core is exceeded in any of the in-memory components, all inputs are dropped to disk. This can have a dramatic impact on performance; but this does not mean that it is always better to increase the value of max-core.
The higher you set the value of max-core, the more memory the component can use. Using more memory generally improves performance up to a point. Beyond this point, performance will not improve and might even decrease. If the value of max-core is set too high, operating system swapping can occur and the graph might fail if memory on the machine is exhausted.
When setting the value for max-core, you can use the suffixes k, m, and g (upper-case is also supported) to indicate powers of 1024. For max-core, the suffix k (kilobytes) means precisely 1024 bytes, not 1000. Similarly, the suffix m (megabytes) means precisely 1048576 (10242), and g (gigabytes) means precisely 10243. Note that the maximum value for max-core is 2g-1.
SORT component
For the SORT component, 100 MB is the default value for max-core. This default is used to cover a wide variety of situations and might not be ideal for your particular circumstances.
Increasing the value of max-core will not increase performance unless the full dataset can be held in memory, or the data volume is so large that a reduction in the number of temporary files improves performance. You can estimate the number of temporary files by multiplying the data volume being sorted by three and dividing by the value of max-core (because data is written to disk in blocks that are one third the size of the max-core setting). This number should be less than 1000. For example, suppose you are sorting 1 GB of data with the default max-core setting of 100 MB and the process is running in serial. The number of temporary files that will be created is:
3 × 1000MB / 100 MB = 30 files
You should decrease the value of a SORT component's max-core if an in-memory ROLLUP or JOIN component in the same phase would benefit from additional memory. The net
performance gain will be greater.
If you get a "Too many open files" error message, your SORT component's max-core might be set too low. If this is the case, SORT can also fill AB_WORK_DIR (usually set to /var/abinitio at installation), which will cause all graphs to fail with a message about semaphores. This
directory is where recovery information and inode information for named pipes are stored and is typically mounted on a small filesystem.
NOTE: We recommend setting the value max-core as a $ reference to a parameter (for example, $AI_SORT_MAX_CORE) so you can easily adjust the value at runtime if required.
In-memory ROLLUP or JOIN
It is difficult to be precise about the amount of memory an in-memory ROLLUP or JOIN will consume. An in-memory JOIN tries to hold all its nondriving inputs in memory, so make the largest input by volume the driving one. A ROLLUP component must hold the size of the keys, plus the size of the temporaries, plus the size of any input fields required in finalize to produce the output. In practice, in most ROLLUP components, this is just the size of the output. In addition, some space is needed for the hash table.
You should always set the max-core parameter in in-memory ROLLUP and JOIN components with a parameter, like AI_GRAPH_MAX_CORE. The default can be set to the appropriate value and changed at runtime if required. You can create additional parameters such as
AI_GRAPH_MAX_CORE_HALF and AI_GRAPH_MAX_CORE_QUARTER to divide up the available max-core among different in-memory components in a phase. If two in-memory components each need most or all of AI_GRAPH_MAX_CORE, you should put them in separate phases, provided you have the disk space to hold the data at the phase break.
A second use of phasing is to control the allocation of memory among in-memory components.
Because there is a limited amount of memory available, you can use phasing to make sure each in-memory component gets a sufficient amount. Typically, only one to four in-memory
components should occupy the same phase, depending on memory availability and demands.
To compute a value for AI_GRAPH_MAX_CORE, take the total memory on the machine and subtract memory used by lookups and competing processes, including other graphs, running at the same time on the machine. This is the available memory. Divide this by twice the number
of partitions to get AI_GRAPH_MAX_CORE max-core is measured per partition, and the factor of two gives a contingency safety factor. So:
AI_GRAPH_MAX_CORE = (total memory - memory used elsewhere)/(2 * number of partitions