Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Paul Raulersonv (pkrauleson_at_verizon.net)
Date: 06/13/04 

Date: Sun, 13 Jun 2004 15:52:59 GMT

Isn't this getting a little bit out of hand?

  Some compilers use entry logic that stores the program name in the stack frame for
  just this purpose.

  On some platforms you can compile with debugging enabled, which will set STABS
  information in the link-edited file, accomplishing the same thing

  Most shops that really want to do this define standard entry-logic for their programs
  which includes a step to store the program name in WS or some other well known space.

   On the mainframe, you have ADATA records that can help you out.

-Paul

"Richard" <riplin@Azonic.co.nz> wrote in message news:217e491a.0406121410.5ac81559@posting.google.com...
> robert.deletethis@wagner.net (Robert Wagner) wrote
>
> > The stack contains a return address. Using that, the program name can usually
>
> The 'return address' need not be to the actual CALLing program. It
> may be to the run-time so that the run-time can decrement the 'active'
> counter or somesuch. The run-time does know which programs are
> active, which is why it can give an error when a re-entry is tried.
>
> > found near the beginning of its segment or in a public symbol table.
>
> I just looked as some object code. Yes the program name is there, so
> are a lot of other names, and in no particular order. This is also
> _not_ a general solution as you claimed and may be entirely specific
> to particualr compilers and environments, each one requiring a
> different solution.
>
> > >But also the CALL does not necessarily go to the called program
> > >directly. It most likely goes to the run-time resolver, so going one
> > >up the stack does not necessarily go to the caller.
> >
> > Let's try to stay in focus. We're interested in the RETURN address, not the
> > call address.
>
> And the return address may be back to the run-time which is where the
> actual entry to the called program came from.
>
> > >So even if one could work out the stack frames to access the calling
> > >program there is still _nothing_ as a 'general-purpose' in that
> > >program that would give that name. If there was then it would also be
> > >in the called program, so walking the stack is unrequired.
> >
> > Heap walkers are a very common diagnostic tool. I'm disappointed to read
> > you're unfamiliar with the concept.
>
> You are now confused between the stack and the heap. They are
> different things you know.
>
> As I said there is still _nothing_ that make this a general solution.
>
> > Yes, it is common practice. ...
>
> > Thinking ahead, I'd developed a tool to track program executions. It shows one
> > of the 15 running every day, the others seldom or never. I change that one.
>
> So, how did you know which one ran ? Obviously not from the
> Program-Id if they were all the same.
>
> How did the program get executed ? Something must have specified its
> name, presumably its file name. Surely you should have been able to
> find which one was run by looking at what CALLed it, or the job cards.
>
> > Months later the file gets broken. Hours of research leads to 'we run that
> > program when someone asks for special handling.'
>
> That shows you have a complete lack of 'thinking ahead'. Either you
> should have changed all 15 or should have 'archived' the other 14 so
> they could be used.
>
> > Yes, it is common practice. ...
>
> > This kind of abuse is WHY big shops are burdened with Change Management
> > software and programmers locked out of the production box.
>
> The 'common practice' and 'burdened by CMS' seem to be incompatible.

Relevant Pages

  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... registers (memory mapped) all sorts of fun things happen. ... When the stack overflows you don't see any allocation errors. ...
    (sci.electronics.design)
  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... that hard to avoid unless your program is doing something very strange. ... There is no real reason to avoid C on any micro when good compilers ...
    (sci.electronics.design)
  • Re: Statement on Schildt submitted to wikipedia today
    ... However, what Schildt described was not an abstract stack, but a specific ... but not true -- many compilers will ... support the contention that the standard was designed "to protect profits". ... "Sequence points" were designed to protect profits, ...
    (comp.lang.c.moderated)
  • Re: [OT] PostLisp, a language experiment
    ... some compilers might compile the ... > of the name is really irrelevant to any discussion of efficiency. ... my discussion with John Doty was based on stack ... apparently no runtime checks for stack mismatches, ...
    (comp.lang.lisp)
  • Re: Stack Overflow
    ... Sub Caller() ... '<<< COMPILER STORES THIS LOCATION ... Sub CalledFunction() ... (Think of it like a stack of plates. ...
    (microsoft.public.excel.programming)