[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GnuCOBOL-Dev] GnuCOBOL file description

From: Ron Norman
Subject: Re: [GnuCOBOL-Dev] GnuCOBOL file description
Date: Mon, 17 Jun 2019 07:28:22 -0400

Feed back on Simon's comments.
1) agree. If present, it can be used, if not present then nothing else can be done.
2) Indicating the IX file format is important. For example, C-ISAM & D-ISAM are compatible but VB-ISAM and BDB are not. If we ever reach a point where GnuCOBOL can handle different IX file formats with the same runtime then knowing the exact file format will help to direct I/O to the correct handler code.
3) It needs to be file basename.dd as that is the only thing that 'may' be unique within the given directory. In the case of "ASSIGN EXTERNAL myname" you only know the real file name by checking for DD_myname in the environment. On IBM mainframes the job control uses // LBL ... // LFD myname to assign a specific file to the ASSIGN name in the COBOL program and the name in COBOL is often something like INPUT or OUTPUT... Same with Unisys 2200s, theĀ @ASG is used to associate the real file name with the name used in the COBOL code. Hard coding path & file names in the COBOL code is a bad idea as it seriously limits flexibility.
4) Having external record format/descriptions is something I have with my commercial software and I understand this well. It is required if you want to be able to access SQL tables as if they where INDEXED data files but this issue is more complex. Not only do you need to handle REDEFINES but you need IF rules which indicate which REDEFINES is being used for a given record and you need data field format conversion for DECIMAL <--> DISPLAY, BINARY, PACKED, FLOAT, etc... and also options for just RAW data (which is useless for SQL usage). This is for some future project for GnuCOBOL and not now.

On Sun, Jun 16, 2019 at 5:59 PM Simon Sobisch <address@hidden> wrote:
In general I like the idea, also for more than IX (and for each IX, not
only BDB) given the notes below.

Some things to consider:

1 most important: the data dictionary should be optional, if it exist it
should be used for verification and possible additional tools

2 The actual library after IX should be removed (most files will be
created with the default library) and it would be bad to have to change
the type when "temporary/output only" files are now created with a
different library.

3 the data dictionary should not take the file basename but the assign
name (which is used in runtime settings for the data otherwise contained
in the dd), this also allows for an optional COB_DICTIONARY_PATH.

4 another new optional entry (maybe one per line) should be added to
contain field descriptions, this allows us to have both external tools
as also a possible cob_file utility to nicely show the files and convert
it (also from/to CSV, for example) those lines should *not* be used for
verification and should support REDEFINE/group items (maybe more or less
copy the FD entries for the file?)


Am 16.06.2019 um 20:48 schrieb Ron Norman:
> Pleas review the attached document about having GnuCOBOL write/read data
> file descriptions using a separate text file in the same directory as
> the data file.
> --
> Cheers
> Ron Norman

Ron Norman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]