× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Tom -

On Thu, 15 Nov 2007 16:23:57 -0600, "Armbruster, Tom"
<Tom.Armbruster@xxxxxxxxxxxxxxx> wrote:

Thanks. I see. A global variable like system time, system date, or
some random global environment variable used by the overall application
by reference could change during the call. That makes the question more
sensible. Although memory is at a premium on some systems, I've always
found that a constant SHOULD be a temporary variable that can not be
altered. I suppose I'm afforded the privilege of quick hit calls on a
high memory system, so short term memory usage hasn't been an issue for
me yet. I forget that not everyone has the budget or benefit of high
availability systems.

I think you missed my point.

I'm NOT talking about any kind of system information or anything which
would be impacted by the system load or any other jobs running on the
system.

I'm talking about global variables in the module. This would be any
file fields and any fields defined in D-specs or C-specs outside of a
procedure.

From one of your previous messages:
READ MyFile
Proc1 ( DREFNO ) // DREFNO is a field in MyFile

DRefNo is a file field so it is a global variable.

Proc1 B
SRefNo LIKE(aField) CONST

If DRefNo has the same length, decimal positions (if applicable), and
type as SRefNo, then a temporary variable is not needed. The code
generated by the compiler will pass the address of DRefNo to Proc1. So
procedure variable SRefNo will pointing to the same memory area within
the program as global variable DRefNo. So within Proc1, any change to
DRefNo will be also be a change to SRefNo.

To put it another way, essentially what's happening in this situation
is ...

SRefNo based(Pointer)

Pointer = %addr(DRefNo)
pass control to Proc1

If SRefNo and DRefNo did not match in characteristics, essentially
what would be happening is ...

SRefNo based(Pointer)
WorkField like(SRefNo)

WorkField = DRefNo
Pointer = %addr(WorkField)
pass control to Proc1

If you want to make sure that a change to DRefNo is not reflected in
SRefNo, you can define your own workfield ...

WorkField like(DRefNo)

WorkField = DRefNo
Proc1(WorkField)

You could also force a temporary variable by the use of an expression
(though I don't particuarly recommend this). If SRefNo is numeric ...

Proc1(DRefNo+0)

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.