Is a General File Maintenance Routine possible?

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.

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

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

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

"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 t
hey
also have the EXTERNAL attribute.

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

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.

"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 compan
y
>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

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.

<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

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