Test results WAS: Re: Can File status checking be dangerous?

Pete Dashwood wrote:
Richard wrote:
On May 21, 7:30 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Clark F Morris wrote:
On Mon, 21 May 2012 13:31:22 +1200, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Yesterday I was looking at some COBOL code (not mine) which did
not transform correctly.

Transformation is a process, part of refactoring and layering
legacy COBOL, that we do where the COBOL codebase gets scanned and
all references to indexed file IO are replaced with invokes of
objects in a Data Access Layer (DAL). (The effect is that the
application program now runs against a Relational Database instead
of against Indexed files, but the processing is exactly the same
as always.) We use a tool that is part of the PRIMA Toolset to do
this: "Transformation". (The tool's actual name is MOSTAMD -
Maintenance Object Server Template Amendments)

It is usually pretty straightforward; the STARTs, READs, WRITEs,
DELETES and REWRITEs are replaced by equivalent method invokes in
the appropriate object and the OPENs and CLOSES (of Indexed files)
are simply commented out. Another phase of MOSTAMD does all the
"Housekeeping", adding thread management, object references, DAL
object program IDs, interface buffers in WORKING-STORAGE and all
the stuff you need to empower procedural COBOL into becoming
capable of using objects. We call the new code "Werewolf" code to
identify it from the Legacy, and because it has undergone a
transformation which makes it much more powerful... :-)

All of this is done completely automatically by the Toolset and
requires no programmer involvement, although it is good to have a
legacy programmer running it, in case there are system
implications or some of the Transformed code does not compile.
(This is a VERY rare event; in a recent case where a client
Transformed more than 800 Legacy PR1ME COBOL programs, there were
6 that required intervention to get them working.)

Anyway, the results from the Werewolf code did NOT match the
results from the Legacy and this caused me some concern, partly
because it is an unusual event and partly because it might
indicate a problem with MOSTAMD.

When I checked the offending Legacy program I found that all the
READs were unscoped.

In other words, there were NO INVALID KEY clauses, NO END-READ,
clauses and NO full stops to indicate the end of the read
statement.

Something like this:

READ INFILE
ADD 1 TO IN-COUNT
IF INFILE-STATUS NOT = "00"
... go and do something about closing down and cleaning up.

The simplest transformation would be to have the INVOKEs for any
file which has a file status declared provide the mechanism for the
object to update the appropriate file status field.

This is already done. There is code in the DAL Objects to translate
SQLCODES into COBOL FILE STATUS which is returned through the
interface. MOSTAMD regnises indexed files which have a file status
defined and ensures that that particular field is updated after
every invoke of a DAL Object method.

This would get tricky
for the WRITE statement because they are associated with records
and not files but if your code has to detect which file it is
dealing with anyway, this shouldn't be too bad.

The File Status is updated for ANY method invoke where the
equivalent RDB table set is accessed. Files and records are
irrelevant. Eaxh File becomes a Table Set on the RDB and there is an
Object to manage each Table Set.

I know that if I declared a file
status, I normally did status code checking exclusively since I
wanted to detect certain conditions (such as INVALID KEY) and
handle all statuses either by accepting the value and taking
appropriate action or going to a termination routine which
displayed as much information (at a minimum the status code, file
name and operation) for all other status codes.

Yes, that is pretty much how I would use it too. However, I don't
recall ever working on a site where File Status was the normal means
of detecting EOF etc. and I certainly wouldn't use it without being
required to (except as a diagnostic tool).

This would get around the problem of detecting scope
and you could still also handle INVALID KEY and AT END as you
currently do in addition to setting the status code.

Sorry Clark, it doesn't solve the scope issue. That is exactly what
prompted this post. Somebody using File Status doesn't think about
end or invalid key conditions as part of the READ and, because of
this, they don't see the need for a scope terminator.

In their mind the READ is finished as soon as they code READ or READ
NEXT/PREVIOUS. When AT END or INVALID KEY and/or NOT AT END/INVALID
KEY is also coded, it makes the programmer think about the structure
of the READ function. This usually leads to a scope delimiter.

The bottom line is that people either use scope delimiters (or a
full stop) or they don't. Unfortunately, READ without any additional
constructs doesn't require a scope delimiter and that is what is
referred to in the topic of this thread.

It is not that it 'doesn't require', it is invalid to add a scope
terminator to an imperative statement.

'READ filename' is an imperative statement.

'READ filename AT END/INVALID/NOT ..' is a conditional statement that
requires scope termination.

'READ filename END-READ' is invalid.

Thanks Richard.

I wasn't aware of that. Probably because I always use the conditional
form.
So you are saying that 'READ filename." is also invalid? (The full
stop is considered to be a scope terminator.)

I guess I need to run some tests...

OK, I ran the tests.

READ INFILE END-READ

READ NEXT END-READ

READ PREVIOUS END-READ

ALL of these imperative forms compile and execute cleanly with the Fujitsu
NetCOBOL compiler V7. Not even a warning.

My understanding was that they would work, so I was surprised when you said:
" 'READ filename END-READ' is invalid."

I thought perhaps misunderstanding may have arisen because you CAN use scope
delimiters but don't HAVE to.

Anyway, the results are clear; READ (in ALL its forms) CAN be scope
delimited. (At least in the Fujitsu implementation, which is the major one I
use.)


Cheers,

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages