× 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.



Re: "CPYTOSTMF always puts the data in arrival sequence?"

Simple answer: Probably, and presumably will always. However, additionally...

CPYTOSTMF does not use the SQL [nor CQE], using instead, the "native" database open and I\O; possibly via the C language. Thus rather than an unordered set, we can presume the result most likely would be either "keyed" or "arrival" sequence. While I see no specific documentation stating that the arrival sequence will be used, I verified in a test [by copying a keyed source physical file] that the "arrival sequence" access path was used. Thus the open of the FROMMBR was *not* a "keyed access path open" [as with the OPNDBF ACCPTH(*FILE)], but instead the equivalent of the OPNDBF ACCPTH(*ARRIVAL), and then sequential reads [implying deleted rows are not read]. However lacking any specific documentation claiming that only arrival sequence will be used, the effect could be nothing more than an implementation detail; i.e. subject to change, such that a future "fix" could cause keyed files to be opened for keyed sequence rather than arrival sequence.

While for many other functions I would expect that any change would have enough complaints to "Make it work like it used to!", I really doubt that there are enough people both creating keyed program described or keyed source physical files and using CPYTOSTMF against those keyed files. Even fewer, if the "one field" rule versus merely "program described" is required for the FROMMBR file. Probably few have ever expected anything other than the arrival sequence access path because most are unaware that the supported FROMMBR could ever be keyed. Although if they did expect ordering according to a keyed access path, probably like most scenarios, they would likely just "assume" that the way it works must be correct... and then code to depend on that effect instead of verifying the documented effect. If instead someone were to complain, and the developers "fix" the feature to honor the key, anyone assuming no change would be [possibly negatively] affected.

Anyone interested in having documented, the specifics regarding the ordering, could submit an electronic comment via the InfoCenter to request the command(s) be updated to reflect the [lack of or a] defined order for the records being copied. Basically, to indicate if the order of the physical rows in the from-member will be the same order as those records written to the TOSTMF, or if the order of the stream file text records is undefined.

Given another response in this thread, by Bryan, showing support for "ORDER BY" via PTF SI45389 [latest supersede presently SI45389] in v7r1 [IBM i 7.1] for CPYTOIMPF provided by APAR SE49612, one could instead of asking for the doc to be updated, just hope that the documentation would be updated for the database export command:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/cl/cpytoimpf.htm

However if an awaited documentation update is as horribly lacking and poorly worded as the APAR, then there surely would be no joy; "allow the user to add a new parameter"? The new parameter keyword is left unnamed, only referred to as the probable PARM TEXT('Order By'), and neither syntax diagrammed nor any example command strings showing uses of the new parameter :-( Almost anybody who applies the PTF to get the new command would probably be able to give a much better description than whoever composed the text for the APAR :-Q
http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/SE49612

Regards, Chuck

On 19-Jan-2012 15:37 , Scott Klement wrote:
Interesting... What you say makes sense, but it didn't occur to me.

I assume that (in contrast to CPYTOIMPF) CPYTOSTMF always puts the
data in arrival sequence?

On 1/19/2012 2:57 PM, CRPence wrote:

FWiW: If the "sequence" of records in the stream text file
matters, then CPYTOIMPF may be a poor choice. That copy\export
utility uses the SQL to generate an _unordered set_ of database
rows which are then written to a stream text file. So unless there
is an ordering feature [e.g. a parameter specification] on the
version of the [CPYTOIMPF] export command being used, do not depend
on the exported data to be in any particular order.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.