On 05-Nov 13:07, Pat Barber wrote:
There are NO S/36 files on the i,
Well... of course. But effective S/36 files or restored S/36 files,
can and do exist. They would be /native/ *representations of* the S/36
files. Calling them "S/36 files" seems just as appropriate, and
simpler, IMO... because:
A DB2 for i DBFile that represents a S/36 DB file is always Program
Described. A native Externally Described file can be used in place of
the S/36 DB file, its external description overridden by program
specifications; i.e. the layout of the file data is program-described or
"described by the program" instead of elsewhere\external to the program.
To call that replacement file a "S/36 file" would be inappropriate
because the concept of Externally Described was not available on the
S/36, even if the IDDU existed for something similar.
The Externally Described file would usually be created by one of the
following interfaces for which effective /source/ exists to create them
again or similar copies, as needed:
- CRTPF SRCFILE() which means the file was described by DDS
- SQL DDL such as CREATE TABLE
- 1=Create in Work with DB Files using IDDU (WRKDBFIDD)
but a very simple DDS that represents the S/36 file.
It may seem just semantics, but the distinction is important:
The database file that represents the "S/36 file" is *not* defined by
DDS, because a file created with DDS can only be Externally Described.
The S/36 file is, as alluded above, always Program Described. What are
manifest as apparent /fields/ [aka columns] might best be called
faux-fields. The distinction is explained further, below.
The following is a 256 byte file with a index key of 11 in the first
11 bytes.
It is externally described but a very VERY short description with
one field and one key description. The system doesn't care if it is
"flat" or "DDS" described, they would work no matter what.
A database file is categorized as *either* Program Described *or*
Externally Described. The former will have what /is presented as/
having a minimal form of an /external description/ yet remain what the
DB2 considers a non-relational /flat/ file. That presentation is by
design, but more accurately, the Program Described file has *no* fields;
would not even require a Record Format, and most definitely not a RcdFmt
level identifier. Although the database accepts references to the
apparent field definitions [these faux-fields] with this minimal
capability [i.e. they are un-tagged, effectively binary EBCDIC,
fixed-length "character" fields], merely for convenience of
implementation, the files are still not considered externally described.
The file shown later, as having been created by BLDFILE is *not*
externally described, just as is noted in the "File Information", even
though two fields descriptions are listed. Those faux fields are listed
merely for ease of and consistency in the implementation of the
composite pieces of the Database *FILE object... albeit that effect can
also muddle the clarity from varying perspectives. For example, if the
/key/ field was not listed in DSPFFD, then the reference to that field
name in the Access Path definition in the DSPFD would confound the user;
having referred to a field that does not exist. But a more proper
effect of DSPFFD just might have been to show *no fields* and then do
something different in DSPFD for PgmDesc vs ExtDesc files.? Similarly,
why show a Record Format at all? Yet, again for convenience, things
like the level identifier, for the consistent existence of the record
format and fields, allows the database to use that information in
restore activity, just as it does for Externally Described files.
SQL would not work because the file is NOT externally described
Some SQL can operate successfully on program-described [aka flat]
files, specifically because the OS DB feature exposes the Record Format
with one [or possibly more] /fields/ to whatever code asks for that
information. The SQL is limited to its access, most notably, according
to the capabilities for fields with those attributes; e.g. those faux
fields will always have CCSID(*HEX), but the SQL could use CAST to
assign a CCSID. As well, because the files are not considered
/relational/ they are omitted from the SQL catalogs, so access can be
very limited to SQL interfaces. In general, SQL access to the data for
DML is fraught with difficulties that are best avoided if possible, by
converting the files to Externally Described and the applications
updated as required to match the changes\conversions to the files.
Note the names created by the system.
The following file was created using BLDFILE command.
The file description states that this file is "NOT" externally
described because of the file creation method.
Yep. Back to that conundrum whereby the /field definitions/ are
exposed [faux fields], even though they effectively do not exist. No
fields, because the file is essentially undescribed except by the
programs that access it; according to each pgm's chosen layout.
Display File Field Description
Input parameters
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : *LIBL
File Information
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : TCS
File location . . . . . . . . . . . . . . . : *LCL
Externally described . . . . . . . . . . . : No
Number of record formats . . . . . . . . . : 1
Type of file . . . . . . . . . . . . . . . : Physical
File creation date . . . . . . . . . . . . : 09/30/13
Record Format Information
Record format . . . . . . . . . . . . . . . : ACCTS
Format level identifier . . . . . . . . . . : 2696BD8B9F35D
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 256
Field Level Information
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
K00001 CHAR 11 11 1 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535
F00001 CHAR 245 245 12 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535
That minimally functional external record format description as
projected by the DSPFFD is not the same as an Externally Described file
created from [and described by] Data Definition Specifications (DDS),
even if many features would be unconcerned in knowing the difference.
One example for which there is a glaring and frustrating exception, is
that there is no ability to CREATE VIEW on the above file, *unless* it
was created instead, as Externally Described.
A simple conversion to native should not take over a few minutes
"IF" you know the correct file layout. It will take longer to key the
DDS than anything else.
For /simple/ files, that may be possible. However like others have
alluded, the data records often are not easily represented with a single
Record Format. Unfortunately there are often multiple variants of
/correct file/ layouts to represent all of the rows of data; i.e. often
they are multi-format physical collections of data in rows\records.
There had been software features sold to help people convert their
files, simply because it was known that there are often multiple
definitions of the data. The tooling typically would parse program
sources to help the programmers define one or more Record Formats. One
was a PRPQ from IBM, that also converted from IDDU.
Yes you can create a S/36 "like" file by using a CRTPF
FILE(TCS/SAMPLE1) RCDLEN(256) but it is still a DDS described file as
far as the system is concerned.
As represented by the faux field, but again, not as described by DDS.
And many but not all features will /see/ the two fields and be able to
use the file that way. Some interfaces will only interrogate the file
as far as its /maximum record length/ and be fully unaware of any
/fields/ at all... because the record format and fields have no meaning
to them; e.g. IDDU and Query/400 when running in S/36EE in S36 mode.
Regards, Chuck
On 11/5/2013 9:08 AM, James H. H. Lampert wrote:
A couple of questions about S/36 files, prompted by a potential
new customer whose whole native system is apparently set up around
them:
First, while I've occasionally futzed around with totally flat,
non-keyed files, and while I've used program-described mode to
circumvent level-check problems on externally-described files that
change regularly, but in a manner that's under our control, I don't
have a lot of experience with actual S-36 files. Am I correct in
my understanding that an S-36 file can be both flat and keyed at
the same time? Is there a convenient way to create a file
indistinguishable from an S-36 file on a V4 or V6 box that doesn't
have any S-36 emulation installed?
Second, can SQL access an S-36 file? Is it difficult?
midrange.com
