Re: Received FTP files have TYPE P

To add to the thread - I don't remember seeing anyone say how FTP works when uploading to a PF - if the file does now exist, it is created as a flat file - this is also true when using FTP to upload a SAVF image and you have either not created the target SAVF or you have not used the SAVF extension on the image.

It was not stated that I remember whether the PF was already there and whether it was created as a table..

Nonetheless, I hope this information will intercept behavior that is seen as strange when using FTP.

Cheers
Vern

On 4/20/2016 8:30 AM, CRPence wrote:

On 19-Apr-2016 06:12 -0500, Rob Berendt wrote:

Hmm, I would have thought that even a DDS table would be a 'T'able
but I was wrong. At least according to SYSTABLES. I didn't expect an
'internally' defined table would be but I would have thought one
with defined columns and whatnot would have been. But testing shows
otherwise. Infor's RCO is a 'P'hysical instead of a 'T'able.

An SQL TABLE is recorded as having the attribute 'TB', in the field DBXATR of file QADBXREF of the System Database Cross-Reference [defined with TEXT('PF-physical,LF-logical,TB-table,VW-view,IX-index')], and all other non-SQL Physical Files are designated as having the attribute 'PF'. Thus both a non-described PF and a DDS-described PF appear as 'P', and a SQL-DDL-described TABLE PF appear as 'T', in the SYSTABLES VIEW; each one-character value designation, being derived from the expression SUBSTR(DBXATR, 1, 1) that defines the TABLE_TYPE FOR TYPE column of that SQL catalog VIEW.

FWiW, a PF that is not externally-described [aka program-described] is designated further, as being non-relational, in the field DBXREL of file QADBXREF of the *DBXREF [defined with TEXT('Relational file: Y=Yes,N=No')]; per the WHERE predicate DBXREL = 'Y', program-described PFs are excluded as rows visible via the SYSTABLES VIEW.