×
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 26-Sep-2016 06:39 -0500, Rob Berendt wrote:
<<SNIP>> Not sure if you can use fclear or fclear64 in the /qsys.lib
file system.
It's worth checking out though.
My first thought in response was that, "Perhaps for the probably very
small number of cases where /sensitive/ data was stored in a member of
either a program-described file or simple source file, then that should
probably function well, if even supported." But then I realized, a
descriptor can be gotten for an externally described file, when opened
for binary. Hmm.
I expect possibly, that the operation might end with ENOTSUP errno
3440 CPE3440 "Operation is not supported." irrespective the database
file attributes. Or possibly the effect would be that the generic
file-system code would translate the fclear request, when the file is a
physical file member, into a request to perform the same method that is
used for Clear Physical File Member (CLRPFM) [though as I had already
alluded in a prior post, that feature my not actually /clear/ the data];
but invoking that method with an option requesting the actual
wipe\zeroing of the database dataspace fixed record length data segments
and the varlen segments.
And maybe that is what I recalled reading somewhere, if not just my
imagination; that the fclear() could effect the secure-delete for DBFs
as well as for STMF.? Not that there was any indication of that
capability noted in the document:
Integrated File System Secure Delete
TechNote: Reference #: N1011726 Historical Number 589273732
[
http://www.ibm.com/support/docview.wss?uid=nas8N1011726]
Clearly the DB could not literally zero their data segments without
additionally truncating\resetting the DataSpace [as is the effect of
CLRPFM, thus by which any future open request would present the
file.member as /empty/], because some field data types could not accept
being reset to all 0x00s, for which the x'00' data would result in bad
data [thus mapping error] for the field.
If a test of fclear() against a /simple/ externally described file
gives success, having verified that indeed the dataspace data segments
were zeroed even if they were released, then [I would] be sure to test
additionally with VARCHAR and LOBs, to verify that the variable segments
are cleared as well; merely indications from the OS [like DSPFD or
DSPPFM] that merely suggest no rows exists is obviously insufficient for
verification. FWiW: I do not have access to SST\D/A/D anywhere, so I
could not do that verification, even if I wanted.
midrange.com
