×
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.
On 14 Oct 2013 04:26, rob@xxxxxxxxx wrote:
How does SAVRSTOBJ use less storage? Doesn't it still save it first?
Just not to anything you can see but instead something in temporary
storage? It's not like it initiates communications before the entire
object is saved, eh? It doesn't start transmission until the entire
object is first saved into temporary storage, right?
Save\Restore works works with /descriptors/ as a sub-component of the
aggregate save. A completed save, e.g. to a save file, could have
consisted of one to many descriptors. The descriptor is essentially a
list of some objects plus all of the data for those selected objects,
that will be saved [aka dumped] to the media device. That list of
objects is not necessarily, and in fact often can not be, /all/ of the
objects that had been requested to be saved on the save-request. After
each descriptor is defined, that ordered list of objects\data is sent to
the Load\Dump feature, that will then dump the objects and their data to
the media in asynchronous tasks. The save component is notified by an
event upon the completion of each dumped descriptor.
Thus, as I understand it, upon the completion of the dump of any one
descriptor, that data can be sent to the target as a completed
sub-component of the save. After each descriptor of objects\data is
sent, then its storage could conceivably be freed on the source system;
and as I recall, effected by the ObjectConnect SAVRST* features.
Similarly the restore works from descriptors, and again can process on a
descriptor-level basis; i.e. all of the ordered objects and their data
are available in each descriptor as a sub-component of the aggregate.
In combination with that understanding, given the capability of an
/application/ to be the recipient of save-records for both save and
restore, the save-file is effectively bypassed entirely by use of a
Save-to-Application Exit-Program and a Restore-from-Application
Exit-Program; i.e. an /application/ replaces the save file as the target
of save-records for a save request and the source of those same
save-records for a restore request.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/XANESAVA.htm
"...
The Save to Application exit program enables an application program to
receive the save records that are generated by a save-to-save-file
operation using the Save to Application (QaneSava) API.
The API calls the exit program once to start the transfer sequence,
multiple times to transfer each block of save records, and once to end
the transfer sequence.
..."
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/XANERSTA.htm
"...
The Restore from Application exit program enables an application program
to provide the restore records that are required for a
restore-from-save-file operation using the Restore from Application
(QaneRsta) API.
The API calls the exit program once to start the transfer sequence,
multiple times to transfer each block of restore records, and once to
end the transfer sequence.
..."
midrange.com
