Re: Is a General File Maintenance Routine possible?

From: Richard (riplin_at_Azonic.co.nz)
Date: 09/18/04


Date: 18 Sep 2004 01:53:16 -0700

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?

Amywhere from easy to impossible, depending on whether one has a full
spec of the virtual machine that allows you to identify what a 'call'
is and where the parameters are and what they mean. Do you have the
full spec of the RM virtual machine ? I thought not.

> >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?

They probably bought it when it was a reasonable company (ie actually
SCO and not Caldera who are the one that called themselves SCO and
then abused the legal system).

> SCO is blatantly abusing the legal system, the computer industry,

I can hardly believe that we agree on something.

> and besmirching Mormonism in the process.

I don't care about _that_, they get told to bugger off, too.

> It's obvious SCO is going broke (again); the only unknown is when.
> Their stock closed today at 1.45,

I don't know where you got that, they have support but no volume as
3.65 at the moment. 1.45 is probably more realistic, especially when
they have set themselves up able to move their cash reserves to the
Canopy group.

> poster's company should be looking for an operating system with longer
> life-expectancy rather than file maintenance tools.

OpenServer can keep running even if SCO folds, it's not like the
licences will expire. As it is trivial to move the system over to
Linux (but will require RM licences) it is only an issue of money.

> >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 ?
>
> I said a full-featured solution would be found in msquery and an ODBC
> driver.

On SCO Unix ? For free ?

> You COULD put inserts at the end of a flat file, but that
> would be clunky. The spec didn't say inserts

Another bit that you missed ?

""" and then you could add records to a file, change records,
delete, print, view, etc."""

> and certainly didn't say
> Fujitsu. You just made that up, then elevated it to "the essence of
> the whole issue."

The 'file maintenace' that you said you could do in 'one program' was
for RM Cobol data files which are _not_ C-ISAM. The file convertion
which was my example of templated generating which you also said you
could do was Fujitsu.

> If I had RM Cobol, I'd write a complete solution and post it here.
> Lacking RM, I post ideas about how it could be done .. and has been
> done on other platforms.

Good deflection. Just write it in a _portable_ way that doesn't
require any dependancies. That's the solution that I suggested.

> Are we developers or consumers? For a consumer solution, call
> Pervasive and get out the checkbook. They have off-the-shelf,
> hold-your-hand software that can do it all. If you want to do it
> yourself, the answer is in programming, not flaming.

How ironic that you say that. I suggest a solution that can be done
in a portable way with no dependancies and your comment was:

   """How ugly."""
   """Rubbish."""
   """Automated cut-and-paste programming at its worst."""

Your suggestions have been non-viable (such as byte reading RM ISAM
files) or cost money (such as Excel, Windows, ODBC drivers, replacing
SCO, TOAD, File-Aid).

Now you attempt to reverse this.
 
> Then why use two different copybooks? The code you posted didn't show
> how input data was copied to output.

Did I use '2 different copybooks' for FDs ? I think not. But then
you do seem to miss much in the messages. No, I didn't show how the
data was copied, it was a small sample to show how the templating was
done.

> This is like talking to an end-user. 'I know what I want to see. I
> won't tell you want it is, but show me something and I'll tell you
> whether you're warm or cold.'

While you don't even seem to read what they do say, you missed 'RM
Cobol', 'SCO Unix', 'adding records'. No wonder you think they never
seem to tell you what they want you simply fail to notice. It is also
no wonder that they keep telling you that you are 'cold', you just go
off and do something 'interesting' rather than anything relevant.

> You're describing an application programmer's attempt to do systems
> programming ..

It is an application programmer's solution to an application
programmer's requirement using application programmer's tools.

> with inappropriate tools.

I suggested Cobol programs, which particular one is 'inappropriate' ?

> People accuse me of using the wrong tool;

Yes they do. So far you have suggested MF specific and C-ISAM specific
tools such as EXTFH and byte accessing ISAM files which fail on RM,
Windows specific tools such as Excel and ODBC flat file drivers that
won't run on SCO Unix. Producing CSV files, putting the file in an
SQL database, File-Aid for DB2, all of which completely miss the
point.



Relevant Pages

  • Terminal Interface Big Problem
    ... I have an SCO Unix 5.0.5 as server and clients Windows PC ... the system interface appears to be completely ...
    (comp.unix.sco.misc)
  • Re: SCO Unix doesnt recognize D-Link network card
    ... I think you've selected the wrong protocol as the card is obviously seen by ... The other PC has Windows 98 to connect with the SCO UNIX ... > server through Telnet. ...
    (comp.unix.sco.misc)
  • old Unix mystery, Re: Access a SCO 3.0 drive from 5.0.6?
    ... Desktop, SCO Open Server, and SCO OpenServer through 5.0.7. ... be an early pre-beta of SCO Unix (from before the first official release, ... System V filesystem, although they might be using 2K blocks which OSR5 ... Upload that file somewhere, post a message here about having done so. ...
    (comp.unix.sco.misc)
  • Re: What is needed to run SCO Openserver 5.0.5?
    ... Does Openserver run ... >>on SCO Unix or is Openserver a version of SCO Unix? ... > licence with SCO and they find out you're using Linux, ...
    (comp.unix.sco.misc)
  • Re: Alternative to SCO - Part 2
    ... long time viable alternative to SCO OpenServer? ... We a mainly a custom programming company who also sells/maintain ... servers for our application at the customer locales. ...
    (comp.unix.sco.misc)