Search Results

Search found 3 results on 1 pages for 'ebm'.

Page 1/1 | 1 

• AIA Artefakte im Oracle Enterprise Repository

  - by Hans Viehmann

  Das Oracle Enterprise Repository (OER) ist die zentrale Stelle zur Verwaltung von SOA Artefakten aller Art, mit dem Ziel, den gesamten Lebenszyklus dieser Artefakte zu begleiten. Es ist wesentliche Grundlage für deren Wiederverwendung, für die Ermittlung von Abhängigkeiten, wie auch für die Bestimmung des Wertes dieser Artefakte, was wiederum für den Nutzen der SOA Implementierung von Bedeutung ist. In AIA 11g wird die aktuelle Version des OER unterstützt und wird zusätzlich ergänzt durch die Project Lifecycle Workbench, in der die funktionale Spezifikation, die Aufteilung der Prozesse, oder beispielsweise die Generierung des Deployment Plans erfolgt.Für die Bereitstellung der Artefakte des Foundation Pack 11g gibt es inzwischen ein zugehöriges AIA Solution Pack für OER, mit dem die entsprechenden Strukturen, sowie die Bestandteile des Foundation Packs 11g, also EBOs, EBMs, EBSs, usw. unabhängig von einer AIA Installation direkt importiert werden können. Das Pack steht auch auf support.oracle.com bereit und kann hier heruntergeladen werden.

  Read the article

• How to debug anomalous C memory/stack problems

  - by EBM

  Hello, Sorry I can't be specific with code, but the problems I am seeing are anomalous. Character string values seem to be getting changed depending on other, unrelated code. For example, the value of the argument that is passed around below will change merely depending on if I comment out one or two of the fprintf() calls! By the last fprintf() the value is typically completely empty (and no, I have checked to make sure I am not modifying the argument directly... all I have to do is comment out a fprintf() or add another fprintf() and the value of the string will change at certain points!): static process_args(char *arg) { /* debug */ fprintf(stderr, "Function arg is %s\n", arg); ...do a bunch of stuff including call another function that uses alloc()... /* debug */ fprintf(stderr, "Function arg is now %s\n", arg); } int main(int argc, char *argv[]) { char *my_arg; ... do a bunch of stuff ... /* just to show you it's nothing to do with the argv array */ my_string = strdup(argv[1]); /* debug */ fprintf(stderr, "Argument 1 is %s\n", my_string); process_args(my_string); } There's more code all around, so I can't ask for someone to debug my program -- what I want to know is HOW can I debug why character strings like this are getting their memory changed or overwritten based on unrelated code. Is my memory limited? My stack too small? How do I tell? What else can I do to track down the issue? My program isn't huge, it's like a thousand lines of code give or take and a couple dynamically linked external libs, but nothing out of the ordinary. HELP! TIA!

  Read the article

• Why first arg to execve() must be path to executable

  - by EBM

  I understand that execve() and family require the first argument of its argument array to be the same as the executable that is also pointed to by its first argument. That is, in this: execve(prog, args, env); args[0] will usually be the same as prog. But I can't seem to find information as to why this is. I also understand that executables (er, at least shell scripts) always have their calling path as the first argument when running, but I would think that the shell would do the work to put it there, and execve() would just call the executable using the path given in its first argument ("prog" from above), then passing the argument array ("args" from above) as one would on the command line.... i.e., I don't call scripts on the command line with a duplicate executable path in the args list.... /bin/ls /bin/ls /home/john Can someone explain?

  Read the article

1