Cobol - Is a General File Maintenance Routine possible?

Author

Is a General File Maintenance Routine possible?

sbelt@dpcsystems.com

2004-09-11, 3:55 am

Is it possible to write a General File Maintenance Routine using
RMCOBOL?

My background is 15+ years programming in a Business Basic language
and everyone had a generalized routine. You could make entries into a
type of data dictionary and a set of programs would read this
directory and then you could add records to a file, change records,
delete, print, view, etc.

Now I'm working for a company using RMCobol and we do not have such a
thing. If you need to access a file, you write a new program. This
just strikes me as a waste of time.

A major difference between BB and COBOL is that BB used variable
length fields and we are using fixed length fields. This seems, to
me, to be the reason no one has attempted such a thing here at this
company.

So two questions:

Using RMCOBOL, is it possible to have a General File Maintenance
Routine?

Has anyone done this and would be interested in selling their routine?
(just in case it's cheaper to buy than write from scratch)

Any input is greatly appreciated.

Frederico Fonseca

2004-09-11, 3:55 am

On Tue, 07 Sep 2004 18:18:01 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Tom Morrison wrote:
>
>It's ages since I used RM, also ages since I used CALLs, and I've never
>coded entry-points. I'm glad Tom stepped in on this one about Relativity
>(which I don't know) - and could be your answer.
>
>But there is another possible solution (freebie) subject to answers to
>following questions - no point in my elaborating until I know.
>
>1 - can you call programs in RM using entry-points ?
No. RM does not support the ENTRY statement.

>2 - using entry-point techniques does not automatically close files like
>a CALL with EXIT PROGRAM, (i.e. the file is in the CALLed program) -
>true/false ?
Issuing a exit program will not close the file on it's own.
Only if you issue a CANCEL of the called program will the files be
closed automatically.

And if the run unit ends (either by a stop run or by a logical end of
the initial program of the run unit) then the files are also closed.

So ways of closing the file are
CLOSE
STOP RUN (implicit or explicit)
CALL followed by a CANCEL (only closes the files opened on the
canceled program).

Don't think there is any other situation where this happens (excluding
sort/merge procedures).

>
>Jimmy, Calgary AB

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

James J. Gavan

2004-09-11, 3:55 am

belt@dpcsystems.com wrote:

>Tom, thank you for your answer. Yes we have and use Relativity but I
>don't think it will fit my current needs perfectly.
>
>
>
Tom I knew the name Relativity - forgive me - I thought is was a product
from the 'other half' when the Merant fiasco was around. Shame on me -
it belongs to Liant. I just took a quick p

at your link.

>Frederico, thank you for answering Jimmy's questions. I've only been
>learning COBOL for a few months, so his questions were technically
>beyond me : ) I did go talk to a couple of our people about "entry
>points" and they say RMCobol does support some form of entry points
>but we don't currently use them enough to be experts on them.
>
>
>
Now that's interesting that your guys imply there is an entry-point
procedure in RM. If anybody knew about it, then I would have thought
Frederico would. Care to think on that one Frederico. So you know where
my mind is going - OO file usage - that you have copies of. Given that
there *were* entry-points then he could emulate that stuff - I think.

Haven't got his name, so I'll have to call him "he". Exactly what are
you after - (a) something that does record generation, (b) as a separate
program entity makes decisions on records, or (c) keep your record
making decisions in your Business program and use a CALLED
vanilla-flavoured file handler per file type ISAM, Relative,
Sequential, Line Sequential ?
(Frederico - without going into specifics he would have to have a copy
of the ISAM template copied to a separate program for each ISAM he has).

I suppose if it was (b), you could do it but I'm really thinking about (c)

I tried as much as possible to stay away from OO - so I wouldn't throw
you. Seems I successfully did - apologies. As a point of interest which
languages have you used other than COBOL. (Guess they can't be C or Java
- otherwise you would have been with me).

>I agree with Frederico's answer to #2. I'm not sure of the answer to
>#1. If you are just wanting to Call a program and within that
>program, jump to a particular section like "Modify an alpha field" or
>"Display the record" or "read the dictionary and paint the screen"
>then my answer would be "Yes it can be done".
>
>Thanks everyone for helping out a COBOL beginner. I hate thinking
>that something can not be done, but I'm begining to think this may be
>a first.............
>
>
>
Just to give you a sense of where my mind is going - if you are content
with 'vanilla' flavoured access and you *really* do have entry-points
think of this OO method as being an entry-point :-

FILE-CONTROL.

Select Data-File
assign Data-filename
organization indexed
access dynamic
record key Data-PrimeKey
file status ws-FileStatus.

FILE SECTION.

FD Data-File
record varying from 20 to 1500 characters *> +++
depending on ws-RecordSize.
01 Data-record.
05 Data-PrimeKey pic x(20).
05 Data-info pic x(1480). *> +++

Note the positioning of the PrimeKey is fixed x(20) although your
CustomerFile A/c # (PrimeKey) might only be 6.
The CALLer (Business program), passes the External filename plus the
true record size of the CustomerRecord to this program(class).

Now to a method accessing by PrimeKey ( and this is your entry-point) :-

Method/Entry-Point "readRecord"
Linkage section.
01 lnk-PrimeKey pic x(20).
01 lnk-Values.
copy "\copylib\sqlResult.cpy" replacing ==(tag)== by ==05 lnk==.
05 lnk-record.
10 occurs 1 to MaxRecordSize
depending on ws-RecordSize pic x.

Procedure Division using lnk-PrimeKey
returning lnk-Values.

initialize lnk-Values
move lnk-PrimeKey to Data-PrimeKey
Read Data-File
key is Data-PrimeKey
invalid key
set RecNotFound to true
not invalid key
move Data-record(1:ws-RecordSize)
to lnk-record (1:ws-RecordSize)
End-Read

if ws-fileStatus = "00" or "23"
continue

else set FileError to true
invoke super "showFileError" using ws-ErrorParams
End-if

OK, so above I've got one of those funny OO "invokes" - substitute :-

else set FileError to true
CALL "FileErrors" using ws-ErrorParams - to 'paint' an
error message box
End-if

1 - if you have entry-points (that's the sticky point - no pun intended)
2 - accept you can put your PrimeKeys in one fixed position (can be 20,
30, 50 etc.). If you want one Alternate key, again fixed, immediately
following the PrimeKey.
3 - stipulate the maximum record size as being your LARGEST file

Then it might be a possible. What do you think Frederico - but excluding
the 'record painting' features ? As regards the latter, I'm into a
particular mindset with OO - I think of the Business program/class (e.g.
Customer Edit) as though it is Stromboli the master puppeteer - he
directs Pinnochio and all his little friends on what their functions are
- CALL record screen
displays (GUIs) and "he" can use WOW, (hope you aren't going to try and
copyright that word Tom :-) ) , CALL accesses to files for data only -
no decision making just results and data. - DBI (Database Interface).

Mr. "He" - this one will definitely blow your mind, but print it off
and get your other guys who claim there are entry-points to take a look.
Where they see the words 'Method-id and End-method' tell them to think
'entry-point'. Go to cobolreport.com and look for Gene Webb's OO
examples. He has one on file handling. It contains everything but the
kitchen sink ! It gives you a very comprehensive picture which can be
simplified. What will throw you is he wraps the OO inside a tool
Rational Rose - just ignore what he is doing with 'Rose'.

Meanwhile I'll send Frederico a very 'old' program that he doesn't have.
It's based on the early techniques of Will Price. One entry point or one
method, using a series of evaluates to Open, Read, ReadNext, Start,
Close etc. - see if this looks like a possible, Frederico. It doesn't
require entry-points. But above all else the CALLEd FileProgram must
stay OPEN between CALLs until he is ready to CLOSE it.

Jimmy, Calgary AB

Frederico Fonseca

2004-09-11, 3:55 am

On Tue, 07 Sep 2004 15:18:24 -0500, sbelt@dpcsystems.com wrote:
Top posting corrected.

>On Tue, 07 Sep 2004 20:30:23 +0100, Frederico Fonseca
><real-email-in-msg-spam@email.com> wrote:
>
>
>Tom, thank you for your answer. Yes we have and use Relativity but I
>don't think it will fit my current needs perfectly.
>
>Frederico, thank you for answering Jimmy's questions. I've only been
>learning COBOL for a few months, so his questions were technically
>beyond me : ) I did go talk to a couple of our people about "entry
>points" and they say RMCobol does support some form of entry points
>but we don't currently use them enough to be experts on them.
>
>I agree with Frederico's answer to #2. I'm not sure of the answer to
>#1. If you are just wanting to Call a program and within that
>program, jump to a particular section like "Modify an alpha field" or
>"Display the record" or "read the dictionary and paint the screen"
>then my answer would be "Yes it can be done".
>
>Thanks everyone for helping out a COBOL beginner. I hate thinking
>that something can not be done, but I'm begining to think this may be
>a first.............
>

Off course it can be done.
Now the work involved will be similar, both with Relativity or with
plain COBOL.

You basically need an application that reads the file info from a
source, and that then "creates" a screen where you can go through the
individual fields/records.

With Relativity you first add the file layout to it's repository, and
then you can access the files using ODBC. There are plenty of programs
around there that allow you to go through a ODBC recordset and
display/modify it. Search the web...

With COBOL.
1- Create a program to read the FD of each file and creat a "screen"
definition of each record.
At the same time create an I/O module to access the file and pass each
record to the "display" program.

2- Create a program to process the "screen" definition created on 1
and process it accordingly.

It seems very easy..but there is a problem. If your file contains
diferent record types you need to add logic to both programs so each
record type has it's specific layout processed. This reduces some of
the automation, but can still be done.

There was a program that Liant supplied (RM/COMPANION) that did pretty
much this. did not allow changing the file, but would display/print
it.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

William M. Klein

2004-09-11, 3:55 pm

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:5g2sj0d4k9oghl3u71fv50lv73rr2sm6i3@
4ax.com...
> On Tue, 07 Sep 2004 18:18:01 GMT, "James J. Gavan" <jjgavan@shaw.ca>
> wrote:
<snip>
>
> And if the run unit ends (either by a stop run or by a logical end of
> the initial program of the run unit) then the files are also closed.
>
> So ways of closing the file are
> CLOSE
> STOP RUN (implicit or explicit)
> CALL followed by a CANCEL (only closes the files opened on the
> canceled program).
>
> Don't think there is any other situation where this happens (excluding
> sort/merge procedures).
>

Semi-obscure,
EXIT PROGRAM (or with the 2002 Standard GoBack) from a sub-program with the
"IS INITIAL" attribute in the Program-ID paragraph closes all files UNLESS they
also have the EXTERNAL attribute.

--
Bill Klein
wmklein <at> ix.netcom.com

Richard

2004-09-11, 3:55 pm

sbelt@dpcsystems.com wrote

> Using RMCOBOL, is it possible to have a General File Maintenance
> Routine?

Yes.

> Has anyone done this

Yes. Around 20 years ago. Also a generalised reporting program.

I had decided that rewriting the same maintenance and the same report
program each time was a complete waste and so started to build a
'synthetic system' that looked after those.

> and would be interested in selling their routine?
> (just in case it's cheaper to buy than write from scratch)

Not really. It is not packaged for others to use, it is not one
'routine' but a design approach. For example most maintenance
programs validate specific fields. I do this by having all valid
values in a 'decode' file keyed by fieldname and value. The screen
layout indicates whether the field is to be validated against the
decode or simply that the description from it is to be displayed (or a
'not found').

It also has such things as security at the field level. When a user
logs on he has a security level. The data dictionary has a security
level on each field. If it is above the user's level then it is noit
moved to the output area and so is not even seen in the report or
maintenance screen. The screen layout also has a security level. If
it is above the user's then the field cannot be changed - it becomes
display only. This means that, for example, for most users they can't
change, say, the debtor's balances, and can't even see the total
sales, yet the manager can.

That particular mechanism is still being used, but I did develop
others. For example I built a code generator for maintenance (a
series of them actually). This could be made to do things that the
synthetic system could not sensibly. It used a text screen layout and
a table, or in fact several for multi-screen maintenance, and built
the core of the screen handling code. The table included call-out
paragraph names for field validation and/or field help (eg stepping
through the decodes) so much coding was still required.

Bob Wolfe

2004-09-11, 8:55 pm

"Tom Morrison" <t.morrison@liant.com> wrote:

><sbelt@dpcsystems.com> wrote in message
> news:sd4sj0dhirlpbd7on1m2tob90qhvrn0mg6@
4ax.com...
>
>Perhaps you could describe which need it doesn't meet. In your original
>post you said, "You could make entries into a
>type of data dictionary and a set of programs would read this directory and
>then you could add records to a file, change records, delete, print, view,
>etc."
>
>Relativity does all of these things. In addition it handles such
>interesting situations as described by other posters, including:
> - multiple record types and other redefinitions,
> - occurs,
> - 'parallel occurs' (where there are multiple actual items with OCCURS
>clause that are logically connected)
> - date conversions for some truly obscure date storage mechanisms.
>Combined with other tools mentioned in this thread, it seems like file
>maintenance is rather easily obtained. In fact, we have several customers
>using it for that purpose!
>
>The only difference is that it does not produce an RM/COBOL program. As
>another poster pointed out, we once sold a (third-party) product called
>RM/Companion which was a report writer program generator; this could have
>been bludgeoned into creating file maintenance programs of a sort. The
>company that developed Companion has since disappeared
>(http://www.albertaventure.com/artic...ed.cfm?id=3161, second company
>listed [Jimmy, any insight?]) and Liant has not sold the product in many
>years.
>
>Best regards,
>Tom Morrison
>Liant Software Corporation
>

Tom:

Brian and Jennifer McNeill's new company is Cyphersoft:

http://www.ciphersoftinc.com/

Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com

James J. Gavan

2004-09-12, 3:55 am

Richard wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote
>
>
>
>
>
>
>
>I think that you have mis-interpreted 'entries'.
>
>
>
>
>Files that are OPENed in CALLed routines, or INVOKEd methods, are
>CLOSED when the calling program CANCELs the routine or issues a STOP
>RUN. A file is not CLOSEd on EXIT PROGRAM regardless of whether the
>CALL was to the program name or an ENTRY point.
>
>
The latter not quite right for OO. If I attach say a File Class to the
'Main' program, having first set a handle(object reference), then I can
leave it OPEN for ever - until STOP RUN.

If I want a transaction file, say File Class - LineSequential - again
establish a handle and open it, and write current transactions - it
doesn't automatically get CLOSEd by your 'Cancel' - there really is no
such animal in OO. (I wish there was - this is one of my problems with
Exception Handling). For example, a 'Parent' Business Class selected
from the Master Menu, which identifies the file and OPENs it as output;
subsequently the parent invokes to write records to that file. Even if I
"hide" dialogs associated with the Business Class, and word my
'main'/'begin' method so that it automatically returns via End-Method
back to the Master Menu - I still wont get an automatic CLOSE. Same
applies currently with M/F's usage of "finalize" methods.

invoke MyBusinesClass "finalize" returning MyBusinessClass (destroys
the object reference)

I haven't tried it, but I betcha the above gives me a memory leak ( the
OPENed file can no longer be referenced although it has a legit
reference), but it's still sat there as OPEN - it would only get CLOSEd
with an Exit from Master Menu Choice giving STOP RUN. So part of my
housekeeping is OPEN files and when the Business program concludes,
CLOSE files.

But anyway - thanks for the clarification on Procedural.

Jimmy, Calgary AB.

Tom Morrison

2004-09-12, 8:55 am

<sbelt@dpcsystems.com> wrote in message
news:sd4sj0dhirlpbd7on1m2tob90qhvrn0mg6@
4ax.com...
> Tom, thank you for your answer. Yes we have and use Relativity but I
> don't think it will fit my current needs perfectly.

Perhaps you could describe which need it doesn't meet. In your original
post you said, "You could make entries into a
type of data dictionary and a set of programs would read this directory and
then you could add records to a file, change records, delete, print, view,
etc."

Relativity does all of these things. In addition it handles such
interesting situations as described by other posters, including:
- multiple record types and other redefinitions,
- occurs,
- 'parallel occurs' (where there are multiple actual items with OCCURS
clause that are logically connected)
- date conversions for some truly obscure date storage mechanisms.
Combined with other tools mentioned in this thread, it seems like file
maintenance is rather easily obtained. In fact, we have several customers
using it for that purpose!

The only difference is that it does not produce an RM/COBOL program. As
another poster pointed out, we once sold a (third-party) product called
RM/Companion which was a report writer program generator; this could have
been bludgeoned into creating file maintenance programs of a sort. The
company that developed Companion has since disappeared
(http://www.albertaventure.com/artic...ed.cfm?id=3161, second company
listed [Jimmy, any insight?]) and Liant has not sold the product in many
years.

Best regards,
Tom Morrison
Liant Software Corporation

James J. Gavan

2004-09-13, 8:55 am

Tom Morrison wrote:

><sbelt@dpcsystems.com> wrote in message
> news:unhrj05jdogr3n5d06lgnra6u135o4aggp@
4ax.com...
>
>
>[snip]
>
>
>
>The tool is named Relativity, and it works for RM/COBOL and Micro Focus
>COBOL.
>http://www.liant.com/products/relativity/
>
>
>
>
>Yes, and yes!! ;-)
>
>
>Tom Morrison
>Liant Software Corporation
>
>
>
>
It's ages since I used RM, also ages since I used CALLs, and I've never
coded entry-points. I'm glad Tom stepped in on this one about Relativity
(which I don't know) - and could be your answer.

But there is another possible solution (freebie) subject to answers to
following questions - no point in my elaborating until I know.

1 - can you call programs in RM using entry-points ?
2 - using entry-point techniques does not automatically close files like
a CALL with EXIT PROGRAM, (i.e. the file is in the CALLed program) -
true/false ?

Jimmy, Calgary AB

Tom Morrison

2004-09-13, 3:55 pm

<sbelt@dpcsystems.com> wrote in message
news:unhrj05jdogr3n5d06lgnra6u135o4aggp@
4ax.com...
> Is it possible to write a General File Maintenance Routine using RMCOBOL?
[snip]
> You could make entries into a
> type of data dictionary and a set of programs would read this
> directory and then you could add records to a file, change records,
> delete, print, view, etc.

The tool is named Relativity, and it works for RM/COBOL and Micro Focus
COBOL.
http://www.liant.com/products/relativity/

> Has anyone done this and would be interested in selling their routine?
> (just in case it's cheaper to buy than write from scratch)

Yes, and yes!! ;-)

Tom Morrison
Liant Software Corporation

Frederico Fonseca

2004-09-13, 3:55 pm

William M. Klein

2004-09-13, 3:55 pm

Richard

2004-09-13, 3:55 pm

"James J. Gavan" <jjgavan@shaw.ca> wrote

[color=darkred]
> It's ages since I used RM, also ages since I used CALLs, and I've never
> coded entry-points.

I think that you have mis-interpreted 'entries'.

> 2 - using entry-point techniques does not automatically close files like
> a CALL with EXIT PROGRAM, (i.e. the file is in the CALLed program) -
> true/false ?

Files that are OPENed in CALLed routines, or INVOKEd methods, are
CLOSED when the calling program CANCELs the routine or issues a STOP
RUN. A file is not CLOSEd on EXIT PROGRAM regardless of whether the
CALL was to the program name or an ENTRY point.

James J. Gavan

2004-09-15, 8:55 pm

sbelt@dpcsystems.com wrote:

>Is it possible to write a General File Maintenance Routine using
>RMCOBOL?
>
>My background is 15+ years programming in a Business Basic language
>and everyone had a generalized routine. You could make entries into a
>type of data dictionary and a set of programs would read this
>directory and then you could add records to a file, change records,
>delete, print, view, etc.
>
>Now I'm working for a company using RMCobol and we do not have such a
>thing. If you need to access a file, you write a new program. This
>just strikes me as a waste of time.
>
>A major difference between BB and COBOL is that BB used variable
>length fields and we are using fixed length fields. This seems, to
>me, to be the reason no one has attempted such a thing here at this
>company.
>
>So two questions:
>
>Using RMCOBOL, is it possible to have a General File Maintenance
>Routine?
>
>Has anyone done this and would be interested in selling their routine?
>(just in case it's cheaper to buy than write from scratch)
>
>Any input is greatly appreciated.
>
>
>
OK - let's go back to square one. Tom mentioned Relativity - but you
indicated not too enthused. Then you said your guys *thought* there were
entry-points - just out of curiosity went looking at RM on-line manuals
- Syntax manual - nothing showing an 'extension' for entry-points in the
CALL syntax.

You mentioned 'screen painting' - RM 'Screen Section' or Windowing ?
Exactly what do you think you want to do at this point in time. There
are several possibilities and in return Frederico sent me a copy of a
program he uses. A word of caution - 15 years in programming - but *new*
to COBOL - watch you don't get burned by your enthusiasm. Are you
talking about a BIG BANG approach - switch everything over on D-Day - or
- can you plan it to finalize current fiscal year-end and run news
features in parallel, (a month or so), for next fiscal year. To convert
- presumably 'current' files and some new - number of files, what sort
of volumes ?

If you do want to pursue with a vanilla-flavoured file approach,
Frederico and I can offer some suggestions - so what's your current
thinking ?

Jimmy, Calgary AB

sbelt@dpcsystems.com

2004-09-16, 3:55 pm

On Wed, 15 Sep 2004 21:18:41 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

Hello Everyone,
>OK - let's go back to square one. Tom mentioned Relativity - but you
>indicated not too enthused.
I'm trying not to increase our deployment costs. While Relativity
has it's uses, it would cost us to give it to each of our customers.
What I'm trying to do is make it easier for us to support our
customers. This file maintenance routine would not be used directly
by our customers but by our programmers - tracing down data problems,
out of balance journals, etc.

> A word of caution - 15 years in programming - but *new*
>to COBOL - watch you don't get burned by your enthusiasm.

LOL - how right you are! Seems like I would learn to curb
the enthusiasm after getting burned so many times. But without
having challenges and the enthusiasm to tackle these challenges,
I don't think I could come to work everyday.

>Then you said your guys *thought* there were
>entry-points -
>
>You mentioned 'screen painting' - RM 'Screen Section' or Windowing ?
>Exactly what do you think you want to do at this point in time.

>Are you talking about a BIG BANG approach - switch everything over on D-Day - or
>- can you plan it to finalize current fiscal year-end and run news
>features in parallel, (a month or so), for next fiscal year. To convert
>- presumably 'current' files and some new - number of files, what sort
>of volumes ?
>
>If you do want to pursue with a vanilla-flavoured file approach,
>Frederico and I can offer some suggestions - so what's your current
>thinking ?
>
>Jimmy, Calgary AB

My original question was "is it possible?" and I really expected just
a Yes or No answer. I thought that the answer would be so easy I
would be very lucky if someone didn't include "stupid" or "dumb
question" in their answer. The part about someone selling their
routine was just an after-thought.

My original criteria for this project, which I did not put in my OP,
was something like:

No additional deployment costs.

There can be no "converting" of data. I do not want to move
any data from a RM file to any other kind of file in order to
manipulate the data. I want to read the data from a RM file
into memory, change it in memory and write back to RM file.

Since RM will not allow anything other than RM to write to a RM
file, it must be written in RM.

It must run on SCO UNIX. No Windows apps.

We have approximately 200 files per customer to deal with. I
can not convert any of these files to anything else. My project
can not change any layouts, formats or anything dealing with
the structure of these files.

>Are you talking about a BIG BANG approach
No.

>If you do want to pursue with a vanilla-flavoured file approach,
>Frederico and I can offer some suggestions - so what's your current
>thinking ?
>Exactly what do you think you want to do at this point in time.
When I do decide to pursue this it would be a very vanilla flavored
approach. I'm not trying to re-invent the wheel - just add a cushion
so the ride is not as ruff.

At this point in time, the project is going on a back burner until I
learn a lot more COBOL. The COBOL examples I've received
here are great even though some have made my eyes glaze over. I
know one day I'll be experienced enough to understand and use
the examples - just not this w

.

I really appreciate all of the input - this is a great group.
Feel free to email me any questions or suggestions.

shawn belt
sbelt@dpcsystems.com

Donald Tees

2004-09-16, 3:55 pm

sbelt@dpcsystems.com wrote:
> On Wed, 15 Sep 2004 21:18:41 GMT, "James J. Gavan" <jjgavan@shaw.ca>
> wrote:
>
> Hello Everyone,
>
>
> I'm trying not to increase our deployment costs. While Relativity
> has it's uses, it would cost us to give it to each of our customers.
> What I'm trying to do is make it easier for us to support our
> customers. This file maintenance routine would not be used directly
> by our customers but by our programmers - tracing down data problems,
> out of balance journals, etc.
>

As a matter of course, I always write a "dump to line sequential
display" routine for every file, along with a "re-load from line
sequential display" routine. Such routines can be written from scratch
in 5 or 10 minutes, and in a pinch you can always patch using a simple
line editor. Crude as heck, but the equivalent of getting out a bigger
hammer to make it fit, plus it always works(provided you know what you
are doing). Also zero incremental costs.

Donald

Robert Wagner

2004-09-16, 8:55 pm

On Thu, 16 Sep 2004 13:03:29 -0400, Donald Tees
<donald_tees@sympatico.ca> wrote:

>As a matter of course, I always write a "dump to line sequential
>display" routine for every file, along with a "re-load from line
>sequential display" routine. Such routines can be written from scratch
>in 5 or 10 minutes, and in a pinch you can always patch using a simple
>line editor. Crude as heck, but the equivalent of getting out a bigger
>hammer to make it fit, plus it always works(provided you know what you
>are doing). Also zero incremental costs.

Most compilers come with a tool for that. Writing a custom program is
unnecessary.

Donald Tees

2004-09-16, 8:55 pm

Robert Wagner wrote:
> On Thu, 16 Sep 2004 13:03:29 -0400, Donald Tees
> <donald_tees@sympatico.ca> wrote:
>
>
>
>
> Most compilers come with a tool for that. Writing a custom program is
> unnecessary.

If you are 500 miles from your software development machine, on a
customer machine at the bottom of a 9000 foot mineshaft, and a file is
XXXXed, then what "most" compilers have as part of the software
development system is quite irrelevant.

Donald

Frederico Fonseca

2004-09-17, 3:55 am

On Thu, 16 Sep 2004 21:54:08 GMT, Robert Wagner
<robert@wagner.net.yourmammaharvests> wrote:

>On Thu, 16 Sep 2004 13:03:29 -0400, Donald Tees
><donald_tees@sympatico.ca> wrote:
>
>
>Most compilers come with a tool for that. Writing a custom program is
>unnecessary.
No. Most compilers DO NOT come with such a tool. What many (and not
most) compilers have is a tool to create a sequential file from an
indexed/relative file. This is not the same as having a "sequential
display" file which is intended as all numeric fields are unpacked,
and readable.

So a customer program to change a file from

01 f1 pic S9(9)V99 COMP-4.
to
01 f1 pic -9(9).99.
is necessary, as no COBOL vendor that I know of has this ability (with
normal COBOL files (not that they are normal!!)).

Use of specific OS files (such as IBM AS400 database files) does not
qualify as normal COBOL files.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Richard

2004-09-17, 3:55 am

sbelt@dpcsystems.com wrote

> What I'm trying to do is make it easier for us to support our
> customers. This file maintenance routine would not be used directly
> by our customers but by our programmers - tracing down data problems,
> out of balance journals, etc.

I would start by defining an interface which includes a whole bunch of
standardised fields and has enough of them to hold the data of every
individual file. eg:

01 Data-Interface.
03 DI-Key PIC X(36).
03 DI-Alternate PIC X(36) OCCURS 5.
03 DI-Flags PIC X OCCURS 30.
03 DI-Words PIC X(4) OCCURS 30.
03 DI-Texts PIC X(36) OCCURS 40.
03 DI-Values PIC S9(10)V9999 OCCURS 50.
03 DI-Dates PIC X(8) OCCURS 15.

Try to keep the number of field type down.

Set up a dictionary for each file that refers to these as F03, W12 etc
and also includes the field name as used in the FD for the file
(hopefully as a copybook).

Now you need one 'maintenance' program that will read the appropriate
dictionary and works with the interface. It will dynamically call a
program to read, rewrite, delete etc the records of the file and will
display, allow amendment, etc.

Now you will need 200 programs that will read, rewrite, etc and will
move data between the record layout and the interface, one for each
file.

To get these 200 programs you will need a template skeleton program,
the copy books, the dictionary and a program that will create the
final 200 programs from these.

I have actually done this sort of thing. For example I needed about 70
file conversion programs which I had copybooks for. One skeleton
template, one control file that had a set of parameters, such as
program name, copybook name, and several other variables and a
template processor and it was all ready.

Now actually I wrote the template processor in Python because the
whole thing is about 20 lines of code in that language, but it could
easily be done in Cobol.

Richard

2004-09-17, 3:55 am

James J. Gavan

2004-09-17, 3:55 am

Donald Tees wrote:

> Robert Wagner wrote:
>
>
>
> If you are 500 miles from your software development machine, on a
> customer machine at the bottom of a 9000 foot mineshaft, and a file is
> XXXXed, then what "most" compilers have as part of the software
> development system is quite irrelevant.
>
> Donald
>
When I first came over here in '75 I was APPALLED at advertising on TV.
Product X shaving soap was displayed, along with two other shaving
soaps. The 'actor' just brushed the competitors off the table ! So here
you are, with a theatrical sweep of your arm, brushing aside a solution
, because it doesn't fit your view.

"Most compilers" ? Which ones. What tool do you have in Server Express
to achieve that. I'm sure Donald would at least be curious because he's
using N/E V 3.0.

Robert Wagner

2004-09-17, 3:55 am

On Thu, 16 Sep 2004 17:57:10 -0400, Donald Tees
<donald_tees@sympatico.ca> wrote:

>Robert Wagner wrote:
>
>If you are 500 miles from your software development machine, on a
>customer machine at the bottom of a 9000 foot mineshaft, and a file is
>XXXXed, then what "most" compilers have as part of the software
>development system is quite irrelevant.

The Earth's crust increases in temperature one degree Farenheit for
every 70 feet down. In the oilfield, we're accustomed to bottom-hole
temperatures around 300F (and pressures around 50000 psi). At 9000
feet, the temperature is at least 180F.

There's your problem .. the disk drive is overheated! And the users
are dead.

[In fact, the world's deepest 'people mine' goes down slightly more
than 1000 feet, where the temperature is 120F.]

Hyperbole aside, I've been there too. I used to support truck stops in
god-forsaken desert locations so remote it took a day and a half to
get there by commercial transport and as long to get out. (Thank god
for general aviation.) Many times I 'called home' at 2400 baud to
download a tool I needed. Today, they have wideband connections. In
the unlikely event they don't, plug your 3G cellphone into the NIC.

Robert Wagner

2004-09-17, 3:55 am

On Thu, 16 Sep 2004 23:20:58 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Donald Tees wrote:
>
>When I first came over here in '75 I was APPALLED at advertising on TV.
>Product X shaving soap was displayed, along with two other shaving
>soaps. The 'actor' just brushed the competitors off the table ! So here
>you are, with a theatrical sweep of your arm, brushing aside a solution
>, because it doesn't fit your view.
>
>"Most compilers" ? Which ones. What tool do you have in Server Express
>to achieve that. I'm sure Donald would at least be curious because he's
>using N/E V 3.0.

DFCONV.

One can also click on Tools/Data Tools/Convert.

Robert Wagner

2004-09-17, 3:55 am

On Thu, 16 Sep 2004 23:47:28 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>On Thu, 16 Sep 2004 21:54:08 GMT, Robert Wagner
><robert@wagner.net.yourmammaharvests> wrote:
>
>No. Most compilers DO NOT come with such a tool. What many (and not
>most) compilers have is a tool to create a sequential file from an
>indexed/relative file. This is not the same as having a "sequential
>display" file which is intended as all numeric fields are unpacked,
>and readable.
>
>So a customer program to change a file from
>
>01 f1 pic S9(9)V99 COMP-4.
>to
>01 f1 pic -9(9).99.
>is necessary, as no COBOL vendor that I know of has this ability (with
>normal COBOL files (not that they are normal!!)).

One solution is don't store comp-anything into a data file. Make
everything DISPLAY. That's what I do.

The other is learn to use a hex editor.

James J. Gavan

2004-09-17, 3:55 am

Robert Wagner wrote:

>
>DFCONV.
>
>One can also click on Tools/Data Tools/Convert.
>
>
>
Yes I've looked at that in V 3.1 - does a neat job turning usage comp
into usage display. Although there is the same in V 3.0 - from memory,
(haven't got V 3.0 on my machine), I don't think it is quite as
enhanced as V 3.1. - V 3.0 will definitely do file 'converts', say from
ISAM to Sequential, but not sure it will give you a 'visual' with the
feature usage display.

Anyway he's still down the bottom of his mine, no matter how friggin hot
it is !

Robert Wagner

2004-09-17, 3:55 am

On 16 Sep 2004 16:11:07 -0700, riplin@Azonic.co.nz (Richard) wrote:

>sbelt@dpcsystems.com wrote
>
>
>I would start by defining an interface which includes a whole bunch of
>standardised fields and has enough of them to hold the data of every
>individual file. eg:
>
> 01 Data-Interface.
> 03 DI-Key PIC X(36).
> 03 DI-Alternate PIC X(36) OCCURS 5.
> 03 DI-Flags PIC X OCCURS 30.
> 03 DI-Words PIC X(4) OCCURS 30.
> 03 DI-Texts PIC X(36) OCCURS 40.
> 03 DI-Values PIC S9(10)V9999 OCCURS 50.
> 03 DI-Dates PIC X(8) OCCURS 15.

How ugly. Why not just parse the copybook when you need a 'schema'? In
the rare event it doesn't exist, create one.

>Now you need one 'maintenance' program that will read the appropriate
>dictionary and works with the interface. It will dynamically call a
>program to read, rewrite, delete etc the records of the file and will
>display, allow amendment, etc.

Yes. You're right there.

>Now you will need 200 programs that will read, rewrite, etc and will
>move data between the record layout and the interface, one for each
>file.

Rubbish. One generalized program can do it all.

>I have actually done this sort of thing.

I have no doubt. Automated cut-and-paste programming at its worst.

> For example I needed about 70
>file conversion programs which I had copybooks for. One skeleton
>template, one control file that had a set of parameters, such as
>program name, copybook name, and several other variables and a
>template processor and it was all ready.
>
>Now actually I wrote the template processor in Python because the
>whole thing is about 20 lines of code in that language, but it could
>easily be done in Cobol.

It could have been done in Real Programming with a single program,
without creating 70 'programs'.

James J. Gavan

2004-09-17, 3:55 am

Robert Wagner wrote:

>On Thu, 16 Sep 2004 23:47:28 +0100, Frederico Fonseca
><real-email-in-msg-spam@email.com> wrote:
>
>
>
>
>One solution is don't store comp-anything into a data file. Make
>everything DISPLAY. That's what I do.
>
>The other is learn to use a hex editor.
>
>
Sometimes you appear to come up with some really good ideas - but I tend
to ignore them - when Bill, Chuck and Richard start POUNDING you and
pick holes.

Surprise - usage display - you are right - but that's because both Pete
Dashwood and Donald have been saying it here for YEARS. So usage comp is
*not* Donald's problem. Assuming N/E V 3.0 *had* all the current DFCONV
features - when he hits his problem, he's not sat with the IDE in front
of him. So independent of the IDE he has programs/classes that he can
invoke to do a textual display of the file.

Similarly there is such a tool with Collections. Create a collection of
'textuals' - wont work with usage comp - then try this

invoke MyCollection "display"

Not frequent use - but a useful one to have. Gives a Mickey Mouse DOS
display of your collection, without any CR/LFs . Just like Donald's
approach - gives you an automatic visual without the IDE being
available. Yes, you could also write
a Callback(Iterator) method to display the collection elements
(line-by-line), to a DOS window, or even print it out.

James J. Gavan

2004-09-17, 3:55 am

Robert Wagner wrote:

Response in Middle -

>On 16 Sep 2004 16:11:07 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>
>
>How ugly. Why not just parse the copybook when you need a 'schema'? In
>the rare event it doesn't exist, create one.
>
>
>
>
>Yes. You're right there.
>
>
>
>
>Rubbish. One generalized program can do it all.
>
>
********
OK ! I really like your programming style. Now put your money where your
mouth is. Bearing in mind the questioner is talking Procedural, and
before you commit, take a look at the RM/Manuals on-line - make sure it
fits Liant - now let us see you go for it ! Also remember, he doesn't
want to bugger around reformatting files, conversions or whatever. He
hasn't said, but I'll say it for him, while he's looking for a vanilla
answer, like it or not he has to change the coding of all his Business
programs that would be calling your FileProgram

No short-cuts now. You did say *ALL* - so ISAM, Relative, Sequential and
LineSequential.

*********

I have actually done this sort of thing.

>
>I have no doubt. Automated cut-and-paste programming at its worst.
>
>
>
>
>It could have been done in Real Programming with a single program,
>without creating 70 'programs'.
>
>
>

Frederico Fonseca

2004-09-17, 3:55 am

On Fri, 17 Sep 2004 01:16:46 GMT, Robert Wagner
<robert@wagner.net.yourmammaharvests> wrote:

>On 16 Sep 2004 16:11:07 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>How ugly. Why not just parse the copybook when you need a 'schema'? In
>the rare event it doesn't exist, create one.
>
>
>Yes. You're right there.
>
>
>Rubbish. One generalized program can do it all.
Can you please quote a COBOL compiler that given the following
structure used when the file is first created
SELECT FICH-CLI ASSIGN TO RANDOM F-CLI
ORGANIZATION INDEXED
ACCESS MODE DYNAMIC
RECORD KEY KEY-CLI-1
ALTERNATE RECORD KEY-CLI-2
FILE STATUS IS FILE-STATUS.
...........
FD FICH-CLI
LABEL RECORDS STANDARD.
01 REG-CLI.
*CONSTITUICAO DO FICHEIRO DE CLIENTES PARA DESPACHANTES
05 KEY-CLI-2.
10 CL-TIPO1 PIC 9.
10 CL-NOME PIC X(45).
10 KEY-CLI-1.
15 CL-TIPO PIC 9.
15 CL-NUM PIC 9(6) COMP.
05 DES-CLI.
10 CL-MORA PIC X(45).
10 CL-CPOST PIC 9(4) COMP.
10 CL-CONTRIB PIC X(10).
10 FILLER PIC X(40).

then allows a program with this changed definition
SELECT FICH-CLI ASSIGN TO RANDOM F-CLI
ORGANIZATION INDEXED
ACCESS MODE DYNAMIC
RECORD KEY KEY-CLI-1
FILE STATUS IS FILE-STATUS.
...........
FD FICH-CLI
LABEL RECORDS STANDARD.
01 REG-CLI.
*CONSTITUICAO DO FICHEIRO DE CLIENTES PARA DESPACHANTES
05 KEY-CLI-2.
10 CL-TIPO1 PIC 9.
10 CL-NOME PIC X(45).
10 KEY-CLI-1.
15 CL-TIPO PIC 9.
15 CL-NUM PIC 9(6) COMP.
05 DES-CLI.
10 CL-MORA PIC X(45).
10 CL-CPOST PIC 9(4) COMP.
10 CL-CONTRIB PIC X(10).
10 FILLER PIC X(40).
to sucessefuly open and process the file.

>
>
>I have no doubt. Automated cut-and-paste programming at its worst.
>
>
>It could have been done in Real Programming with a single program,
>without creating 70 'programs'.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Richard

2004-09-17, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> How ugly. Why not just parse the copybook when you need a 'schema'? In
> the rare event it doesn't exist, create one.

Because, if you had read the message, it is a standardised interface
between the maintenance program and the dozens of individual files.
It will be used in the CALL filehandler USING ...

'Parsing a schema' doesn't necessarily achieve the interfacing, but
please do provide a solution if you wish.

>
> Rubbish. One generalized program can do it all.

That is something that you may wish to demonstrate.

>
> I have no doubt. Automated cut-and-paste programming at its worst.

Actually, at its best. Program generators can be completely automated
using a make file so that it becomes a completely fix and forget.
Change the fd copybook and the program is regenerated.

>
> It could have been done in Real Programming with a single program,
> without creating 70 'programs'.

What are you suggesting ? One program with 70 fd copybooks ? Perhaps
you could show some code about how you would do it.

<shrug> I code up one template to do one simple thing and create a set
of parameters to reproduce that as many times as I need. I don't need
to be a self-appointed 'Real Programmer', I can do it with little
effort and create simple code that works and that everyone can
understand.

The issue is productivity. I can do it this way in

Here is a simplified sample of a template:

IDENTIFICATION DIVISION.
PROGRAM-ID. %(programid)s.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT IN-File ASSIGN In-Name
ORGANIZATION SEQUENTIAL
FILE STATUS File-Status

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 01:32:26 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Robert Wagner wrote:
>
>Surprise - usage display - you are right - but that's because both Pete
>Dashwood and Donald have been saying it here for YEARS. So usage comp is
>*not* Donald's problem.

Frederico didn't get the word. See above.

> Assuming N/E V 3.0 *had* all the current DFCONV
>features - when he hits his problem, he's not sat with the IDE in front
>of him. So independent of the IDE he has programs/classes that he can
>invoke to do a textual display of the file.

DFCONV can be run from the command line. Under the covers, the IDE is
calling a batch program.

Donald's programs aren't doing a display, they're copying the file to
line sequential. Then he uses a text editor on them.

>Similarly there is such a tool with Collections. Create a collection of
>'textuals' - wont work with usage comp - then try this
>
> invoke MyCollection "display"
>
>Not frequent use - but a useful one to have. Gives a Mickey Mouse DOS
>display of your collection, without any CR/LFs . Just like Donald's
>approach - gives you an automatic visual without the IDE being
>available. Yes, you could also write
>a Callback(Iterator) method to display the collection elements
>(line-by-line), to a DOS window, or even print it out.

I need the ability to search for a key, edit records and rewrite or
delete them. Text editors provide all that.

Donald Tees

2004-09-17, 8:55 pm

Robert Wagner wrote:
> On Thu, 16 Sep 2004 17:57:10 -0400, Donald Tees
> <donald_tees@sympatico.ca> wrote:
>
>
>
> The Earth's crust increases in temperature one degree Farenheit for
> every 70 feet down. In the oilfield, we're accustomed to bottom-hole
> temperatures around 300F (and pressures around 50000 psi). At 9000
> feet, the temperature is at least 180F.
>
> There's your problem .. the disk drive is overheated! And the users
> are dead.
>
> [In fact, the world's deepest 'people mine' goes down slightly more
> than 1000 feet, where the temperature is 120F.]
>

Your temperatures may be right, but your distances are out by a factor
of 10. Most mines in Ontario go down at least 4-5000 feet. I do indeed
have a computer at 8600 feet, and I have indeed been down to it. It is
a 35 minute elevator ride each way. Where the hell do you get off
telling people in here that I am a liar?

> Hyperbole aside, I've been there too. I used to support truck stops in

Obviously not. First you tell me I am a liar engaged in Hyperbole, then
you tell me you have also done the same. Which is it?

> god-forsaken desert locations so remote it took a day and a half to
> get there by commercial transport and as long to get out. (Thank god
> for general aviation.) Many times I 'called home' at 2400 baud to
> download a tool I needed. Today, they have wideband connections. In
> the unlikely event they don't, plug your 3G cellphone into the NIC.
>

Having software development tools, and having the facility to
export/inport ASCII data from every file in an application are not the
same thing.

You can also be assured that Canada has places that are more remote than
a telephone, eithor land line or cell.

Donald

Donald Tees

2004-09-17, 8:55 pm

Robert Wagner wrote:
> On Fri, 17 Sep 2004 01:32:26 GMT, "James J. Gavan" <jjgavan@shaw.ca>
> DFCONV can be run from the command line. Under the covers, the IDE is
> calling a batch program.
>
> Donald's programs aren't doing a display, they're copying the file to
> line sequential. Then he uses a text editor on them.
>
>

<snipage>

> I need the ability to search for a key, edit records and rewrite or
> delete them. Text editors provide all that.
>

How you do it "under the covers" is quite irrelevant. The key to the
issue is that every *applicaion system*, not every *software
developement system* have, built into it, a file dump/reload that is
shipped as part of the application, and is usable from a simple menu.

We get requests a dozen times a year for such a generic tool after the
fact. What the original programmer had back when they wrote the program,
or even what software tools mights be sitting in a library somewhere is
not a lot of help. "File dump" in a menu is. I can patch or convert
from that.

Donald

Howard Brazee

2004-09-17, 8:55 pm

On 16-Sep-2004, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

> No. Most compilers DO NOT come with such a tool. What many (and not
> most) compilers have is a tool to create a sequential file from an
> indexed/relative file. This is not the same as having a "sequential
> display" file which is intended as all numeric fields are unpacked,
> and readable.

As a mainframe programmer, I don't think of any of those as being compiler
tools. Compilers compile. There are scads of other tools better designed
for dumping data.

PCs have a different idea of what a working environment should be. Their
operating systems aren't designed for programming. Instead of such utilities
as sorts and dumps, PCs are designed for end-users. It doesn't mean their
OSes are any smaller.

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 03:01:26 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:

>Robert Wagner wrote:

>OK ! I really like your programming style. Now put your money where your
>mouth is.

I did two months ago, and again in reply to Richard (same thread).

> Bearing in mind the questioner is talking Procedural, and
>before you commit, take a look at the RM/Manuals on-line - make sure it
>fits Liant - now let us see you go for it !

Every Cobol compiler can read and write 1-byte records.

>Also remember, he doesn't
>want to bugger around reformatting files, conversions or whatever. He
>hasn't said, but I'll say it for him, while he's looking for a vanilla
>answer, like it or not he has to change the coding of all his Business
>programs that would be calling your FileProgram

We're all talking about slightly different things here. My and
Richard's programs copy a file, converting fields to display. That
plus a text editor and reverse conversion is a crude way to update a
file.

My approach could be (and has been) enhanced to produce a General File
Maintenance Routine. Writing it again is probably unnecessary because
others have done it better. Three that I'm familiar with are Toad
($60), Msquery (comes with Excel) and File-Aid for DB2 (n/a). There
are dozens more. Add an ODBC driver and you're in business.

>No short-cuts now. You did say *ALL* - so ISAM, Relative, Sequential and
>LineSequential.

Liant has an ODBC driver for all their formats.

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 07:47:24 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>Can you please quote a COBOL compiler that given the following
>structure used when the file is first created
> SELECT FICH-CLI ASSIGN TO RANDOM F-CLI
> ORGANIZATION INDEXED
> ACCESS MODE DYNAMIC
> RECORD KEY KEY-CLI-1
> ALTERNATE RECORD KEY-CLI-2
> FILE STATUS IS FILE-STATUS.

>then allows a program with this changed definition
> SELECT FICH-CLI ASSIGN TO RANDOM F-CLI
> ORGANIZATION INDEXED
> ACCESS MODE DYNAMIC
> RECORD KEY KEY-CLI-1
> FILE STATUS IS FILE-STATUS.

>to sucessefuly open and process the file.

You're right. Alternate keys cannot be omitted because updates would
mess up indexes. A utility would have to include them when
constructing a file definition at execution time. They are probably
in the file header. If not, it would have to parse source code.

Robert Wagner

2004-09-17, 8:55 pm

On 17 Sep 2004 01:10:50 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>Because, if you had read the message, it is a standardised interface
>between the maintenance program and the dozens of individual files.
>It will be used in the CALL filehandler USING ...
>
>'Parsing a schema' doesn't necessarily achieve the interfacing, but
>please do provide a solution if you wish.

Two months ago I posted cob2csv.cbl, which parsed a copybook into a
structure in memory, a schema, then converted any file from sequential
to comma-delimited. A sample input looked like this:

01 WWICTLG.
10 CTLGOP-CO-NO PIC X(3).
10 CTLGCONTROL-SET-SEQ-NO PIC S9(9) USAGE COMP.
10 CTLGINVOICE-SEQ-NO PIC S9(4) USAGE COMP.
10 CTLGAP-CNTRL-ENTITY-CD PIC X(4).
10 CTLGINVOICE-TYPE-CD PIC X(2).
10 CTLGLEGACY-VENDOR-NO PIC X(10).
10 CTLGAP-VENDOR-NO PIC X(30).
10 CTLGAP-PO-NO PIC X(30).
10 CTLGAP-INVOICE-NO PIC X(30).
10 CTLGINVOICE-DT PIC X(10).
10 CTLGTOTAL-INVOICE-AM PIC S9(11)V9(2) USAGE COMP-3.
10 CTLGTOTAL-MERCH-AM PIC S9(11)V99 USAGE COMP-3.
10 CTLGTERMS-CD PIC XX.
10 CTLGCARRIER-CD PIC X(10).
10 CTLGCARRIER-PRO-NO PIC X(10).
10 CTLGSHIP-DT PIC X(10).
10 CTLGSHIP-VIA-CD PIC X(3).
10 CTLGSHIP-LOC-NO PIC X(3).
10 CTLGSHIP-WT PIC X(10).
10 x redefines CTLGSHIP-WT PIC X(10).
10 CTLGSHIP-UNITS-DC PIC X(10).
10 CTLGSHIP-TY PIC X(2).

The normalized description looked like this:

Lvl Name Pos Len Typ Occ
1 10 ctlgop-co-no 1 3 x 1
2 10 ctlgcontrol-set-seq-no 4 4 b 1
3 10 ctlginvoice-seq-no 8 2 b 1
4 10 ctlgap-cntrl-entity-cd 10 4 x 1
5 10 ctlginvoice-type-cd 14 2 x 1
6 10 ctlglegacy-vendor-no 16 10 x 1
7 10 ctlgap-vendor-no 26 30 x 1
8 10 ctlgap-po-no 56 30 x 1
9 10 ctlgap-invoice-no 86 30 x 1
10 10 ctlginvoice-dt 116 10 x 1
11 10 ctlgtotal-invoice-am 126 7 2 p 1
12 10 ctlgtotal-merch-am 133 7 2 p 1
13 10 ctlgterms-cd 140 2 x 1
14 10 ctlgcarrier-cd 142 10 x 1
15 10 ctlgcarrier-pro-no 152 10 x 1
16 10 ctlgship-dt 162 10 x 1
17 10 ctlgship-via-cd 172 3 x 1
18 10 ctlgship-loc-no 175 3 x 1
19 10 ctlgship-wt 178 10 x 1
20 10 ctlgship-units-dc 188 10 x 1
21 10 ctlgship-ty 198 2 x 1
Record length 199

>
>That is something that you may wish to demonstrate.

A generalized program cannot rely on the compiler to setup its file IO
at compile time; it must do its own setup at execution time. I've used
three approaches. One sets up a file description block at execution
time and calls Cobol's file system. That's especially easy with Micro
Focus because its EXTFH interface is well documented. With other
compilers, you have to figure it out by looking at generated code.
Write a program containing one of each file type, fixed and variable,
and procedural code to do every possible operation. Generated code
will reveal the contents of the file descriptor and call interface.

A second approach uses ODBC drivers, dynamic SQL and an external
schema defining record layouts. Many people are unaware there are ODBC
drivers for flat files (cames standard with Windows) and many Cobol
indexed file formats.

A third approach is lower level than the first two. Defining a random
file with record length of one byte gives the program access to every
byte in the file. That's now cob2csv does it.

select any-file assign to file-name
organization is relative
access is random
relative key is relative-key
file status is file-status.

fd any-file.
01 file-byte pic x.

Read a record like this:

perform varying record-byte from 1 by 1 until record-byte > record-len
read any-file
move file-byte to record-byte (record-len)
add 1 to relative-key
end-perform

For speed in a real-world program, I'd have two FDs -- one with
512-byte records (size of a disk sector) and the other with 1-byte
records, used to read the last partial sector. That's a technical
improvement; concept is the same.

The third approach may or may not work for indexed files. It does for
Micro Focus CISAM, the default form on Unix. And it does for indexed
copied to record sequential via the compiler-supplied tool.

> Program generators can be completely automated
>using a make file so that it becomes a completely fix and forget.
>Change the fd copybook and the program is regenerated.

Except when you forget to run the make file after changing the
copybook. Or you're in a sweltering mine shaft.

>What are you suggesting ? One program with 70 fd copybooks ? Perhaps
>you could show some code about how you would do it.

Cob2csv has code handling individual packed and binary fields. Its
field normalizations looks like this:

05 input-number pic s9(15)
05 redefines input-number
10 input-number-byte occurs 15 pic x(01)

05 input-binary comp-5 pic s9(18)
05 redefines input-binary
10 input-binary-byte occurs 8 pic x(01)

05 input-packed packed-decimal pic s9(15)
05 redefines input-packed.
10 input-packed-byte occurs 8 pic x(01)

convert-number.
move zero to input-number
compute t = length of input-number - layout-length (l) + 1
perform layout-length (l) times
move input-byte (i) to input-number-byte (t)
add 1 to i, t
end-perform
move input-number to work-number

convert-binary.
move zero to input-binary
if input-byte (i) greater than x'7F'
move -1 to input-binary
end-if
compute t = length of input-binary - layout-length (l) + 1
perform layout-length (l) times
move input-byte (i) to input-binary-byte (t)
add 1 to i, t
end-perform
move input-binary to work-number

convert-packed.
move zero to input-packed
compute t = length of input-packed - layout-length (l) + 1
perform layout-length (l) times
move input-byte (i) to input-packed-byte (t)
add 1 to i, t
end-perform
move input-packed to work-number

>Here is a simplified sample of a template:
>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. %(programid)s.
> ENVIRONMENT DIVISION.
> INPUT-OUTPUT SECTION.
> FILE-CONTROL.
> SELECT IN-File ASSIGN In-Name
> ORGANIZATION SEQUENTIAL
> FILE STATUS File-Status
> .
> COPY "%(filesa)s".
> DATA DIVISION.
> FILE SECTION.
> FD IN-File.
> 01 IN-Record.
> 03 IN-Data PIC X(%(recordsize)s).
> 03 IN-CRLF PIC XX.
> COPY "%(filefd)s".

Not shown above is a second FD for the output file. All 70 FDs were
MANUALLY translated, and SELECTs were manually created. That's not an
automated solution.

My conversion to csv could easily be changed to write fixed-length
display fields. The user would need only three things: the input file,
the copybook and my executable. When a new file is discovered, it will
work there too .. without updating a make file, manually creating two
copybooks and running a generate/compile.

What if the user is not a Cobol programmer? I could send him or her
one executable. You'd have to send a compiler, a make utility, a
Python interpreter, and a document explaining how to write copybooks.

Tom Morrison

2004-09-17, 8:55 pm

> My original criteria for this project, which I did not put in my OP,
> was something like:
>
> No additional deployment costs.
>
> There can be no "converting" of data. I do not want to move
> any data from a RM file to any other kind of file in order to
> manipulate the data. I want to read the data from a RM file
> into memory, change it in memory and write back to RM file.

Shawn,

One of the biggest issues for you is, "How will I build a data dictionary?"

Since you already have the Relativity SDK, you can use it as a toolkit to
build an accurate dictionary. You can the use the Relativity Designer's
built-in reporting mechanism to export the physical schema (i.e. the file
record layouts), and use that export as input to a program generator to
generate maintenance programs.

An alternative source of information for building a data dictionary would be
the allocation map in the listing file. The Relativity route would be
easier, since it would generate exactly the dictionary information you would
be looking for, some of which would need to be inferred from an allocation
map. Relativity also allows you to enhance/supplement the dictionary
information.

WRT "No additional deployment costs" you really should talk to the Liant
sales folks about licensing terms specific to the described use.

Best regards,
Tom Morrison
Liant Software Corporation

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 08:04:19 -0400, Donald Tees
<donald_tees@sympatico.ca> wrote:

>Robert Wagner wrote:
>
>Your temperatures may be right, but your distances are out by a factor
>of 10. Most mines in Ontario go down at least 4-5000 feet. I do indeed
>have a computer at 8600 feet, and I have indeed been down to it. It is
>a 35 minute elevator ride each way. Where the hell do you get off
>telling people in here that I am a liar?

I learned you're right. I apologize.

My factor is not off. Deep mines are

ed by circulating air from
the surface. If an 8000 foot mine has water entering, the water
temperature will be 180F.

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 13:54:18 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>PCs have a different idea of what a working environment should be. Their
>operating systems aren't designed for programming. Instead of such utilities
>as sorts and dumps, PCs are designed for end-users. It doesn't mean their
>OSes are any smaller.

Windows ships with a general-purpose file sort, several scripting
languages, and several text editors. If you have Excel (doesn't
everyone?), you have access to most databases .. remote as well as
local.

docdwarf@panix.com

2004-09-17, 8:55 pm

In article <g81mk0d9u5beccsm1b229g7hcnkhjqbdrq@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

[snip]

>If you have Excel (doesn't
>everyone?)

Pardon my mid-sentence interruption, Mr Wagner, but to answer that
parenthetically-expressed question - no.

DD

Frederico Fonseca

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 15:00:43 GMT, Robert Wagner
<robert@wagner.net.yourmammaharvests> wrote:

>On Fri, 17 Sep 2004 07:47:24 +0100, Frederico Fonseca
><real-email-in-msg-spam@email.com> wrote:
>
>
>
>
>
>You're right. Alternate keys cannot be omitted because updates would
>mess up indexes. A utility would have to include them when
>constructing a file definition at execution time. They are probably
>in the file header. If not, it would have to parse source code.
I am right, but you missed the point.

My change code very well have been increasing the size of the key.
The final effect would be the same. e.g. the program would not be able
to process the file because the file definition on the program did not
mach the physical file definition (as stored on the file itself.)
And this is the real problem.
In order to have a generic program reading an indexed file (as
indexed, not as a binary 1 byte file), the select and the file
definition would need to be the same in ALL files.
This would be a plain stupid thing to do.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 15:12:06 GMT, "Tom Morrison"
<t.morrison@liant.com> wrote:

>One of the biggest issues for you is, "How will I build a data dictionary?"
>
>Since you already have the Relativity SDK, you can use it as a toolkit to
>build an accurate dictionary. You can the use then Relativity Designer's
>built-in reporting mechanism to export the physical schema (i.e. the file
>record layouts), and use that export as input to a program generator to
>generate maintenance programs.

Is either the Relativity schema or export compatible with your ODBC
driver?

If yes, there are many query and reporting tools that could be used.

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 17:36:05 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>On Fri, 17 Sep 2004 15:00:43 GMT, Robert Wagner
><robert@wagner.net.yourmammaharvests> wrote:
>
[color=darkred]
>I am right, but you missed the point.
>
>My change code very well have been increasing the size of the key.
>The final effect would be the same. e.g. the program would not be able
>to process the file because the file definition on the program did not
>mach the physical file definition (as stored on the file itself.)
>And this is the real problem.

You missed my point. You think the only way to communicate information
about keys is via SELECT. It is not. One can construct a file
description block at execution time before opening the file.

Given that the information about keys is in the file header, the
program can read it using a random FD and put it into the file
description before opening the indexed FD.

Tom Morrison

2004-09-17, 8:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:f95mk0ln8psf9kmkiba5jhorppn05b19de@
4ax.com...
> Is either the Relativity schema or export compatible with your ODBC
> driver?

Relativity is the brand name (registered trademark) for Liant's ODBC driver
for RM/COBOL and Micro Focus COBOL data files.

Relativity has a Designer component which is used by the application
developer to develop the catalog (very enhanced data dictionary) which is
then deployed with the ODBC driver component. The Designer can process
COBOL source or the symbol tables embedded in RM/COBOL object files to
produce the physical schema. The application developer then uses the
Designer to describe the mapping of COBOL record layouts/data items to SQL
tables/datatypes. This includes mapping data items containing date/time
information (in a myriad of formats) to SQL dates, resolving multiple record
types (redefinition in both the large - record level - and small scale),
determining NULL representations where appropriate, normalizing OCCURS, etc.

A detailed explanation of all this may be found in an on-line white paper:
http://www.liant.com/download/pdf/theoryweb.pdf.

For the truly self-abusive, you may find additional interest in the US
Patent 5,826,076,
http://patft.uspto.gov/netacgi/nph-...RS=PN/5,826,076

>
> If yes, there are many query and reporting tools that could be used.
>

Yes that is the idea behind Relativity: provide ODBC (and JDBC) access to
COBOL data files without the need for data warehousing, etc. so that all
those ODBC- and JDBC-enabled tools may be used.

Shawn has expressed concern about the additional cost of goods sold if his
company were to adopt Relativity. While the deployment cost is fairly
small, if you cannot justify any additional cost to the end-user, then the
value proposition is not favorable to adoption.

Best regards,
Tom Morrison
Liant Software Corporation

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 17:26:49 GMT, "Tom Morrison"
<t.morrison@liant.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:f95mk0ln8psf9kmkiba5jhorppn05b19de@
4ax.com...
>
>Relativity is the brand name (registered trademark) for Liant's ODBC driver
>for RM/COBOL and Micro Focus COBOL data files.
> ...
>A detailed explanation of all this may be found in an on-line white paper:
>http://www.liant.com/download/pdf/theoryweb.pdf.

Now Relativity is clear. Thank you.

IBM mainframers may be interested to know the ODBC driver also
provides access to MVS files.

>For the truly self-abusive, you may find additional interest in the US
>Patent 5,826,076,
>http://patft.uspto.gov/netacgi/nph-...RS=PN/5,826,076

I skimmed it wondering about Prior Art. People have been accessing 3GL
files via ODBC for many years. The patent is about the Relativity
schema format and tools that maintain it.

William M. Klein

2004-09-17, 8:55 pm

Actually, Robert

The IBM mainframe compilers are "notorious" for the fact that you don't need the
exact same Alternate Record Key descriptions when doing Updates as you do when
creating the files.

I *know* that you can create a file with 2 alternate keys - and then update (or
read) the file with only one alternate key. I have not tried creating it with 1
alternate key - and then updating it with 0 alternate keys - but it wouldn't
surprise me if this were accepted.

Originally, in the '85 Standard this would have caused a FS=39 - but later on it
was "clarified" that it is up to each vendor WHICH "fixed file attributes" were
to be checked to cause a FS=39.

I believe (but won't swear to it) that if one uses the LATEST Micro Focus MFEEE
product, that this "behavior" has been emulated by MF - due to "user demand"
*not* to check alternate keys for FS=39.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:5urlk01s0hf0g3ummigickib27g1htjcp6@
4ax.com...
> On Fri, 17 Sep 2004 07:47:24 +0100, Frederico Fonseca
> <real-email-in-msg-spam@email.com> wrote:
>
>
>
>
>
> You're right. Alternate keys cannot be omitted because updates would
> mess up indexes. A utility would have to include them when
> constructing a file definition at execution time. They are probably
> in the file header. If not, it would have to parse source code.
>
>
>
>

Richard

2004-09-17, 8:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Every Cobol compiler can read and write 1-byte records.

In some cases that can be very slow (in my actual experience).

> We're all talking about slightly different things here. My and
> Richard's programs copy a file, converting fields to display.

You obviously didn't read the specification, or didn't understand it.
My programs were to convert files. Specifically this was from MF
C-ISAM (or Level II) format to Fujitsu ISAM.

> That
> plus a text editor and reverse conversion is a crude way to update a
> file.

Now the 'reverse conversion', was that to be to a one byte file ?

>
> Liant has an ODBC driver for all their formats.

Excuse me but I don't think that covers your program _writing_ an ISAM
file using Fujitsu Cobol.

Robert Wagner

2004-09-17, 8:55 pm

On Fri, 17 Sep 2004 18:50:34 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I believe (but won't swear to it) that if one uses the LATEST Micro Focus MFEEE
>product, that this "behavior" has been emulated by MF - due to "user demand"
>*not* to check alternate keys for FS=39.

That's been in EXTFH for some time. See the KEYCHECK parameter in File
Handling/Configuration. The default is on.

"Specifies whether the File Handler checks that the key definition
defined in your application matches that of the indexed file you are
opening."

William M. Klein

2004-09-17, 8:55 pm

Not quite the same thing (but probably used to emulate the IBM mainframe
behavior - which checks some things - just not that all the alternate keys are
specified)

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:5edmk0955to10if2276pph4fptmgloooh6@
4ax.com...
> On Fri, 17 Sep 2004 18:50:34 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> That's been in EXTFH for some time. See the KEYCHECK parameter in File
> Handling/Configuration. The default is on.
>
> "Specifies whether the File Handler checks that the key definition
> defined in your application matches that of the indexed file you are
> opening."
>

Howard Brazee

2004-09-17, 8:55 pm

On 17-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

>
> In some cases that can be very slow (in my actual experience).

Are you saying that every Cobol compiler can compile a program that can read and
write 1-byte records? Compilers read source code and libraries.

I once converted programs from small Burroughs to large Burroughs (In 1980,
converting words such as PC to PIC). One trouble came because of the SORT verb
not working with a file until I padded out the record size. The record size
was too little.

Richard

2004-09-17, 8:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Two months ago I posted cob2csv.cbl, which parsed a copybook into a
> structure in memory, a schema, then converted any file from sequential
> to comma-delimited. A sample input looked like this:

[color=darkred]
> A generalized program cannot rely on the compiler to setup its file IO
> at compile time; it must do its own setup at execution time. I've used
> three approaches. One sets up a file description block at execution
> time and calls Cobol's file system. That's especially easy with Micro
> Focus because its EXTFH interface is well documented.

The MF EXTFH was specifically implemented to give such flexability,
yes. Had the specification been for MF Cobol I may have suggested
using this. Unfortunately the requirement was quite clearly for RM
Cobol.

> With other
> compilers, you have to figure it out by looking at generated code.
> Write a program containing one of each file type, fixed and variable,
> and procedural code to do every possible operation. Generated code
> will reveal the contents of the file descriptor and call interface.

RM Cobol isn't 'generated code', it is byte code (last time I looked).
This is quite easy to decode, but only if you have the full
description of the byte code engine.

> A second approach uses ODBC drivers, dynamic SQL and an external
> schema defining record layouts. Many people are unaware there are ODBC
> drivers for flat files (cames standard with Windows) and many Cobol
> indexed file formats.

Just two little points you may have overlooked. First it clearly
specified SCO Unix (probably OpenServer rather than UnixWare), and
secondly it required no end user cost.

> A third approach is lower level than the first two. Defining a random
> file with record length of one byte gives the program access to every
> byte in the file. That's now cob2csv does it.

> select any-file assign to file-name
> organization is relative
> access is random
> relative key is relative-key
> file status is file-status.
>
> fd any-file.
> 01 file-byte pic x.
>
> Read a record like this:
>
> perform varying record-byte from 1 by 1 until record-byte > record-len
> read any-file
> move file-byte to record-byte (record-len)
> add 1 to relative-key
> end-perform

Just two little, trivial really, problems. First your 'solution' may
work with C-ISAM files which are essentially fixed length data records
in the data file, but this is for RM. Once again you take a single
data point and extrapolate without understanding that this doesn't
work.

The second problem is writing back into the ISAM file, a point you
have completely failed to cover and which is the essence of the whole
issue, or of both issues actually. You have now travelled down a
complete dead-end. Explain how you will insert a record and update
the index on an RM ISAM file, or a Fujitsu one. Will you use your 1
byte file to fiddle the index ?

> The third approach may or may not work for indexed files. It does for
> Micro Focus CISAM, the default form on Unix.

It is the default for _MicroFocus_ on Unix.

> And it does for indexed
> copied to record sequential via the compiler-supplied tool.

> Except when you forget to run the make file after changing the
> copybook.

Well, actually it would be the same makefile as is used for every
other program in the system. So if you forget to run the make then
the programs that use the file will also not be recompiled.

> Or you're in a sweltering mine shaft.

I am not sure that the development system is down the mine, or on any
customer machine, I think that was also part of the requirements
statement.

>
> Cob2csv has code ...

Well you have certainly tried to show how clever you can be, it is
just a shame that all that code solves some other problems entirely
and doesn't address any of the problem at hand.

Specifically you haven't shown how you would write the data back to,
say, an RM ISAM file on SCO Unix.

> Not shown above is a second FD for the output file. All 70 FDs were
> MANUALLY translated, and SELECTs were manually created. That's not an
> automated solution.

This was the file conversion from C-ISAM to Fujitsu. The FDs were not
required to have anything at all done with them. There was no 'manual
creation' they already existed. Certainly for the maintenance
programs the FD would need to be parsed to create the MOVEs to the
interface and back.

> My conversion to csv could easily be changed to write fixed-length
> display fields. The user would need only three things: the input file,
> the copybook and my executable. When a new file is discovered, it will
> work there too .. without updating a make file, manually creating two
> copybooks and running a generate/compile.

And if a CSV was an appropriate result we would all say 'well done',
but actually it isn't.

> What if the user is not a Cobol programmer? I could send him or her
> one executable. You'd have to send a compiler, a make utility, a
> Python interpreter, and a document explaining how to write copybooks.

Now why would all that be required ? The program runs at the
development site where the RM compiler and the source code is located
and the resulting executables are delivered to the end user along with
the executables for the system.

I am not selling a packaged solution to a developer, I am suggesting a
solution that they can implement, the executables from which are sent
to the end user.

I think that you have clearly missed all the requirements of the task
and have, as you have often done, made up a 'solution' to a completely
different task.

Robert Jones

2004-09-17, 8:55 pm

message snipped

Hello Shawn

To go off on a somewhat different tack, I would be very wary of
fiddling with files without using the programs designed for the
purpose in a production system. Certainly, for accounting purposes
such as the journals you mentioned, an audit trail of all changes is
highly desirable, and an accountant might be very unhappy with changes
being applied in such an ad-hoc manner as you suggest.

Many organisations would also be generally unhappy about changes being
applied in such an unregulated manner and you would have to be careful
to ensure that the people using such tools have the appropriate
authorisation.

By all means buy, borrow or write general purpose update facilities
but try to restrict your use of them to test environments, they can be
very useful for tweaking test data to satisfy particular conditions.
A print program for each file is often a useful asset, especially if
it also checks and reports fields with invalid data.

As others have mentioned there are several professional products that
will provide batch or online updating of files, using copybooks to
present the data in an easily manipulable form, some might be
shareware or free if you do the appropriate online searches. Some
have even suggested ways of you doing this yourself.

Regards, Robert

Tom Morrison

2004-09-17, 8:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:5samk09shog31hem7ccpipiohi6bht8u6i@
4ax.com...
[snip]
> IBM mainframers may be interested to know the ODBC driver also
> provides access to MVS files.

If this is meant to say that Relativity is available for MVS files on a
mainframe, this is no longer true. That product has been withdrawn from the
market. If you came to this conclusion from our marketing materials on the
web, please tell me where (I didn't see any mainframe references in a quick
review).

There *do* exist ODBC drivers for MVS files from other companies. They are
not as feature rich as Relativity (see below) in my estimation (but I
stopped evaluating these products several years ago).

>
>
> I skimmed it wondering about Prior Art. People have been accessing 3GL
> files via ODBC for many years. The patent is about the Relativity
> schema format and tools that maintain it.

Of course, prior art is acknowledged in the patent disclosure and the
twenty-three claims speak for themselves, assuming one can interpret
patent-ese. The advances of the art are significant in the area of dealing
with, for lack of a better term, automatic normalization of typical COBOL
data structures and data definition practices.

Tom Morrison

Richard

2004-09-17, 8:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Windows ships with a general-purpose file sort,

I doubt that it would be regarded as 'general-purpose'. It does sort
ascii text files.

> several scripting languages,

Several ? Well DOS batch hardly counts but may minimally pass as
such. Windows scripting doesn't seem to be a general purpose
scripting language. What else ? JavaScript ?

> and several text editors.

Do they still ship edlin ? I can think of NotePad and WordPad, are
there others ?

> If you have Excel (doesn't everyone?),

Certainly not.

Robert Wagner

2004-09-17, 8:55 pm

On 17 Sep 2004 12:46:24 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
>RM Cobol isn't 'generated code', it is byte code (last time I looked).
>This is quite easy to decode, but only if you have the full
>description of the byte code engine.

All you want to know are call parameters and file description
structure. How hard can that be?

>
>Just two little points you may have overlooked. First it clearly
>specified SCO Unix (probably OpenServer rather than UnixWare), and
>secondly it required no end user cost.

SCO! I missed that. Why would anyone support a company that's trying
to destroy Unix and Linux by suing everyone in sight? SCO is blatantly
abusing the legal system, the computer industry, and besmirching
Mormonism in the process