Finding documentation for ancient Progress 5.2? - Forum - OpenEdge General - Progress Community

Finding documentation for ancient Progress 5.2?

 Forum

Finding documentation for ancient Progress 5.2?

  • G'day,

    I've inherited an ancient Progress 5.2 database and application, running on SCO OpenServer (!).  Just wondering if anyone here has any doco for such an old version?  I'd like to be able to write some stuff to manage this old database, and maybe export data from it into CSV or something so I can do some processing on it?

  • Maybe someone have that in a library or something ... I've worked with that version/OS about 25 to 28 years ago.  It does have an administrative tool that would allow you to export the data in text format files (dump).

    Would you be interested in upgrading it to more recent version?

  • Thanks Perdigao, I had a quick look, can't find "dump" in /usr/dlc (default location for binaries, I think?)

    $ ls d*

    dbf

    demo.db

    dict.p

    dict.p-

    dict.r

    $ pwd

    /usr/dlc

    The only dump on the system is in /etc/pwr/lib - so something to do with power management, not progress.  This is an ancient system!  We won't be upgrading it, I just want to get some data out of it.

    Is dump a command line tool or something else?

  • V5 predates me, but at a guess, try the dictionary (dict.p). There might be an option in there to dump the data.

  • No, it is not …
     
    You have to start it like this:
     
    Probably _progress (but I don’t remember).
     
    _progress <<database name>>  -1 –p dict.p
     
    The -1 is for single user mode
     
    If you don’t have _progress, please list the bin directory and provide us the list of files there …
     
    Good Luck,
     
    Ricardo Perdigao
     
  • You can also try:
     
    pro <<database name i.e: test.db>> –p dict.p
     
    or
     
    /usr/dlc/bin/pro <<database name i.e.: /usr/app/db/name.db>> –p /usr/dlc/dict.p
     
     
  • Carl,
     
    Out of pure curiosity:
     
    If this can wait until Monday, please send me an email (rperdiga@progress.com) with a time in the afternoon and I will help you do a dump of the data (I am on EST time).
     
    All the best,
     
    Ricardo Perdigao
     
  • Great, thanks guys!  I'm grabbing a dump from /usr/dlc/pro aam.db -p dict.p - I had to kill the server first, but this is on a VM and I just grabbed a copy to play with - you can't run SCO UNIX on modern hardware, virtualisation saves the day :)

  • I don't think v5 had a "bin" directory.  Things were organized much more simply in those days.

    --
    Tom Bascom
    tom@wss.com

  • fewer executables, only 5 or thereabouts, but there were the usual wrappers for them so you can do

    pro foo

    bpro foo

    proserve foo

    mpro foo

    mbpro foo

    promon foo

    dictionary text format dump was the main form of data dump available.

    much of the 4GL you know is there. no gui, no app server, no connecting multiple databases, no dataservers.

    i have v5 doc in my office, but i am at home now so i can't look at it.

  • Digging up an old thread.  I have a need now to run a nightly dump of the database.  I can use /usr/dlc/pro to get at my database "aam", but it goes into a curses interface, is there a command line way to do a dump of all the data, rather than go through the menu system?  I can write an expect script if necessary, but would prefer not to.  Not sure how well expect would work on a SCO terminal anyway!  

    Suggestions? I know .. migrate to a new version, won't happen for a _long_ time ...

  • Does dump_d.p exist in V5.2?

    Check:

    MESSAGE SEARCH("prodict/dump_d.r").

    How to dump data from the database from within your application

    knowledgebase.progress.com/.../P103503

  • G'day George, I don't think so, but there is a prodict/dbudump.p

    I have a VM running a copy of the production server that I can have a good play with, doesn't matter if I break anything

  • Old kbase article has a hint (dbload.p -> dbdump.p?) :

     Solution: 146 Type: N

        Title: Dictionary  Dump/Load when using filename > 9 chars

    Written by dah 07/12/89

    If you change a field name into a name of more than 9 characters the load procedure will abort because Progress is using the datatype field to store the name.

    The workaround is to add the appropriate format into dbload.p where you prompt-for the datatype.

    See bug#89-11-15-06

  • I have a V5 tutorial and Reference. I looked through both. The one thing I found might be of interest to you is, there was a utility as part of the Developer's Toolkit, called mkdump. But, aside of saying it exists, and you can use it to "supply a dump/reload facility to Query/Run-Time or Run-Time users." There's not much in here about it...

    As much as I remember it would create programs, two for each table in the db (dump and load each). But I am not sure anymore about this...

    I can't remember, but I think V5 did not yet have a scriptable utility to dump stuff. The one we have today was introduced with V6.

    Thomas Hutegger

    tmh@smat-consulting.com

    SMAT-Tools - Web-Apps with RollBase simpleness, ABL flexibility and power