|
It's possible that the OS would generate a runtime error if you tried but I have never tried.
No. It doesn't generate any errors, nor should it. It's perfectly legitimate to set an indicator to *NULL.
Pointers just refer to something. They aren't the thing that they refer to. You can think of them the way you'd think of a key variable for a database file (which _refers_ to a particular record, but isn't the record itself.)
Let's say you have a packed field named CustNo in some program you've written. You use it to store a customer number that references a record in your Customer Master file. Should that record be deleted if you set CustNo = 0? If not, should setting CustNo = 0 generate a runtime error?
Pointers are just variables that refer to a spot in a computer's memory (or, on i5/OS, to "storage", which may be disk or memory) Setting them to *null (which is hex zeroes) shouldn't have any impact on the memory they previously pointed to. Just as changing a "CustNo" field won't change the record it previously pointed to.
Statement one deallocates the storage and set the pointer to null.
No, it doesn't change the value of the pointer at all.DEALLOC tells the operating system that the program is done with an area of the systems memory so that it can be made available to other programs. Much like deleting a file may make the disk space available to other programs. Of course, the operating system needs to know which space in memory you're referring to, so you tell it by passing a pointer as a parameter to the DEALLOC opcode. However, it doesn't change the value of the pointer, it only uses it to deallocate that memory.
Just as deleting a record doesn't zero out the field values. Deleting a file doesn't blank out the filename from the variable you passed to the DLTF command, etc, etc.
DEALLOC does have an optional (N) extender that tells it to set the pointer to null -- just a convienience feature, mind you -- but don't think of deallocating and setting the pointer to null as being related, you'll just get yourself confused.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
