Re: SFTP Questions

[CRPence <CRPbottle@xxxxxxxxx>]

  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.