Re: Are level checks still useful?

[CRPence <CRPbottle@xxxxxxxxx>]

On 01 Nov 2012 08:45, Gqcy wrote:
> We are a larger shop, but I too am struggling with the same thing
> in that the PHP/MYSQL people scratch their head (more like point
> fingers at me and snicker) when we struggle with level check.

  Difficult for someone to understand the value of something so 
unfamiliar, having never known\perceived a specific need, even though 
they have likely experienced several situations for which they might 
benefit.  Their applications likely have experienced data errors which 
either were not handled correctly or had to be coded for, rather than 
being warned when the file(s) were originally opened.  They likely do 
not understand how their applications could be prevented [in advance] 
both from encountering the possible data issues and from having coded 
anything to handle the definitional differences because they would know 
they could respond to the level-check error by recompiling.  And those 
who had ever coded for some possible data errors arising from database 
changes, then they were effectively coding level-checking as an 
after-the-fact reactive versus as a before-the-fact proactive 
implementation of the LvlChk feature.

> I have a project to convert DDS to DDL, but I am waiting for IBM to
> change the QSQGNDDL api, to include the record selection into a SQL
> index. We had been thinking that we could somehow migrate the
> database from DDS to DDL, and keep the same format level.

  FWiW: A message thread within the year had indicated some 
new\additional difficulties [similar to others in the past] in matching 
Record Format Level Identifiers between SQL DDL-created and DDS-created 
database files.  There was an implication that IBM had no intention to 
address the newer issue(s), though no APAR documenting that response. 
Anyone hoping to get the match will probably want to pursue that issue 
again, getting a published response confirming the problem will not be 
corrected, or the published fix.

> When a shop is converting from DDS to DDL, should we turn off level
> check?

  I would not, nor would I recommend that.

  Although the LVLCHK() "level check" is a feature established [enabled 
or disabled] at definition-time, i.e. by CRTxF for DDS and CREATE for 
SQL DDL or by CHGxF], the actual function of level checking the record 
format identifier [against the stored value in the application program 
or utility] is activated\relevant only for run-time features.  The 
run-time open request will test the level according to the choice for 
either that definitional attribute or the run-time override to turn-off 
that attribute [e.g. via OVRDBF LVLCHK(*NO)].  Thus the ability to 
safely ignore\defeat the level-check feature generally, as established 
on database files, depends on a switch also being made away from those 
features dependent upon the LvlChk feature; i.e. moving to use only 
those application\programming features which do not depend upon the 
LvlChk feature.

  Turning off level checking effectively requires moving from non-SQL 
interfaces to SQL interfaces, not merely for "create", but additionally 
for "open".  Moving from DDS to DDL is a definitional-only move, so any 
applications that have not yet moved away from languages\utilities that 
depend upon the level check, by moving to SQL-implemented utilities and 
the SQL itself, then turning off level checking will leave any non-SQL 
utilities and applications open to the possible data issues the LvlChk 
intends to help prevent.  I would not ever turn off level check for all 
files even if I assumed all access would be via SQL, because the ease of 
using a non-SQL interface [RCVF by CL is a simple example] is too great, 
such that almost for sure the eventuality of that becoming a "failed 
assumption" for which unexpected\incorrect output was the effect.

  So even though SQL does not *need* level checking, the SQL is not 
immune from all data type attribute changes no matter what some SQL\PHP 
developers may imply.  They still may suffer from database changes even 
with strong support from good DBA and application programmers.... 
changes that require code changes and thus recompile, even though the 
SQL might be able to automatically handle most impacts from database 
changes.  For example, the possibility of overflow conditions do not 
magically get prevented by the SQL after older constraints have been 
expanded beyond the capabilities of the original data typing.  If the 
originally coded SQL program does not have the foresight to code to 
handle larger values than the constraints allow [or to somehow handle an 
overflow], because the SQL does not level check but instead 
automatically handles casting to the other data type attributes, the 
effect may be somewhat like data errors that might transpire for lack of 
having used LvlChk with non-SQL programming.