Re: Are level checks still useful?

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.