+ Reply to Thread
Results 1 to 9 of 9

Progress 9.1D

  1. Progress 9.1D

    I'm trying to install a Manufacturing control package which uses Progress as it's backend database. The
    package is Vista from Epicor. The database is running on Red Hat Linux 7.3. I installed per the
    documentation and started the server (proadsv -start). The next step says to copy the application's database
    files from CD then use the prostrct repair filename command. This bombs out saying it can't create a lock
    file but it actually does create the file. Epicor told me to change the filename.st file to mirror the path
    on the server, I did that but get the same exact error. Can anyone familiar with Progress tell me the correct
    syntax of the .st file. Also if you could point me to an online resource for command syntax it would help.
    The Vista package comes with CDs, no manuals, no man pages, and issuing prostrct --help only produces errors.


  2. Re: Progress 9.1D

    Post your *.st file so we can take a look.

    "rowan @rownetco.com>" <"rowan wrote in message
    news:3F6799DB.7010505@rownetco.com...
    > I'm trying to install a Manufacturing control package which uses Progress

    as it's backend database. The
    > package is Vista from Epicor. The database is running on Red Hat Linux

    7.3. I installed per the
    > documentation and started the server (proadsv -start). The next step says

    to copy the application's database
    > files from CD then use the prostrct repair filename command. This bombs

    out saying it can't create a lock
    > file but it actually does create the file. Epicor told me to change the

    filename.st file to mirror the path
    > on the server, I did that but get the same exact error. Can anyone

    familiar with Progress tell me the correct
    > syntax of the .st file. Also if you could point me to an online resource

    for command syntax it would help.
    > The Vista package comes with CDs, no manuals, no man pages, and issuing

    prostrct --help only produces errors.
    >




  3. Re: Progress 9.1D

    Full progress documentation is available at

    http://web.progress.com/products/doc...tion/index.ssp

    The prostrct repair command generally looks something like

    prostrct repair dbname st-filename

    Each line in the structure file identifies the location of one of the
    several files that make up your Progress Database. It should be obvious
    what needs to be changed when you open the file, which is a flat ascii
    file. You can use any text editor to change it.


    rowan wrote:
    > I'm trying to install a Manufacturing control package which uses
    > Progress as it's backend database. The package is Vista from Epicor.
    > The database is running on Red Hat Linux 7.3. I installed per the
    > documentation and started the server (proadsv -start). The next step
    > says to copy the application's database files from CD then use the
    > prostrct repair filename command. This bombs out saying it can't create
    > a lock file but it actually does create the file. Epicor told me to
    > change the filename.st file to mirror the path on the server, I did that
    > but get the same exact error. Can anyone familiar with Progress tell me
    > the correct syntax of the .st file. Also if you could point me to an
    > online resource for command syntax it would help. The Vista package
    > comes with CDs, no manuals, no man pages, and issuing prostrct --help
    > only produces errors.
    >


    --
    /* =============================================================== */

    I know you believe you understand what you think I said, but I am not
    sure you realize that what you heard was not what I meant.

    William E Colls President
    Tel 613 591 0079 PROComputer Systems
    Fax 613 591 3924 67 Willow Glen Dr.
    www.procomsys.com Kanata Ontario K2M 1T1

    Specialists in Progress Database systems since 1986


  4. Re: Progress 9.1D

    Kalen Marra wrote:
    > Post your *.st file so we can take a look.
    >
    > "rowan @rownetco.com>" <"rowan wrote in message
    > news:3F6799DB.7010505@rownetco.com...
    >
    >>I'm trying to install a Manufacturing control package which uses Progress

    >
    > as it's backend database. The
    >
    >>package is Vista from Epicor. The database is running on Red Hat Linux

    >
    > 7.3. I installed per the
    >
    >>documentation and started the server (proadsv -start). The next step says

    >
    > to copy the application's database
    >
    >>files from CD then use the prostrct repair filename command. This bombs

    >
    > out saying it can't create a lock
    >
    >>file but it actually does create the file. Epicor told me to change the

    >
    > filename.st file to mirror the path
    >
    >>on the server, I did that but get the same exact error. Can anyone

    >
    > familiar with Progress tell me the correct
    >
    >>syntax of the .st file. Also if you could point me to an online resource

    >
    > for command syntax it would help.
    >
    >>The Vista package comes with CDs, no manuals, no man pages, and issuing

    >
    > prostrct --help only produces errors.
    >
    >
    >


    Here's the st file:
    [root@metalica Db]# cat mfgsys.st
    # generated by PROREST on Fri Mar 14 10:20:36 2003
    b /usr/epicor/mfgsys60/Db/mfgsys.b1
    #
    d "Schema Area":6,64 /usr/epicor/mfgsys60/Db/mfgsys.d1

    [root@metalica Db]#


  5. Re: Progress 9.1D

    "rowan" <"rowan"@rownetco.com> wrote in
    news:3F68661B.3000807@rownetco.com:

    >
    > Here's the st file:
    > [root@metalica Db]# cat mfgsys.st
    > # generated by PROREST on Fri Mar 14 10:20:36 2003
    > b /usr/epicor/mfgsys60/Db/mfgsys.b1
    > #
    > d "Schema Area":6,64 /usr/epicor/mfgsys60/Db/mfgsys.d1
    >
    > [root@metalica Db]#
    >


    This .st file looks fine.. Is /usr/epicor/mfgsys60/Db the directory where
    these files reside?? Does root have write perms on these files?? The .db
    gets updated when you run prostrct repair and all the others will need to
    be read/write at run time.

    Kevin


  6. Re: Progress 9.1D

    Kevin wrote:
    > "rowan" <"rowan"@rownetco.com> wrote in
    > news:3F68661B.3000807@rownetco.com:
    >
    >
    >>Here's the st file:
    >>[root@metalica Db]# cat mfgsys.st
    >># generated by PROREST on Fri Mar 14 10:20:36 2003
    >>b /usr/epicor/mfgsys60/Db/mfgsys.b1
    >>#
    >>d "Schema Area":6,64 /usr/epicor/mfgsys60/Db/mfgsys.d1
    >>
    >>[root@metalica Db]#
    >>

    >
    >
    > This .st file looks fine.. Is /usr/epicor/mfgsys60/Db the directory where
    > these files reside?? Does root have write perms on these files?? The .db
    > gets updated when you run prostrct repair and all the others will need to
    > be read/write at run time.
    >
    > Kevin
    >


    Yes, /usr/epicor/mfgsys60/Db is the location of the files. I had ownership set to rowan.vistaadmin for the
    files. I changed that to root.root and tried again but the same failure:
    [root@metalica Db]# prostrct repair mfgsys mfgsys.st
    Database Repair: Unable to create lock file. (6928)
    [root@metalica Db]#
    [root@metalica Db]# date
    Wed Sep 17 10:28:29 EDT 2003
    [root@metalica Db]# ls -l *.lk
    -r--r--r-- 1 root root 38 Sep 17 10:26 mfgsys.lk
    [root@metalica Db]#



  7. Re: Progress 9.1D

    "rowan" <"rowan"@rownetco.com> wrote in
    news:3F686F26.7070304@rownetco.com:

    >
    > Yes, /usr/epicor/mfgsys60/Db is the location of the files. I had
    > ownership set to rowan.vistaadmin for the files. I changed that to
    > root.root and tried again but the same failure: [root@metalica Db]#
    > prostrct repair mfgsys mfgsys.st Database Repair: Unable to create
    > lock file. (6928) [root@metalica Db]#
    > [root@metalica Db]# date
    > Wed Sep 17 10:28:29 EDT 2003
    > [root@metalica Db]# ls -l *.lk
    > -r--r--r-- 1 root root 38 Sep 17 10:26 mfgsys.lk
    > [root@metalica Db]#
    >
    >
    >


    Hmm.. Progress support (http://esupport.progress.com) only has one issue
    with this behavior on Linux:
    Issue No: P17735
    Cause: This is a known issue - the hostname must be less or equal to 28
    character on Linux.

    What do the rest of the files look like??

    Kevin

  8. Re: Progress 9.1D

    "rowan" <"rowan"@rownetco.com> wrote in
    news:3F687F66.5080904@rownetco.com:

    >
    > Kevin, you nailed it. The host name was
    > metalica.derickssheetmetal.com which exceeded the 28 characters. I
    > changed to metalica.dsmw-hmf.com, rebooted and the rebuild went
    > without a hitch.
    >
    > I have numerous other problems that I'll tell Epicor to stop working
    > this particular one to focus on those.
    >
    > Thanks for your help.
    >
    >
    >


    Excellent!!

    Good luck..

    Kevin

  9. Re: Progress 9.1D

    Kevin wrote:
    > "rowan" <"rowan"@rownetco.com> wrote in
    > news:3F686F26.7070304@rownetco.com:
    >
    >
    >>Yes, /usr/epicor/mfgsys60/Db is the location of the files. I had
    >>ownership set to rowan.vistaadmin for the files. I changed that to
    >>root.root and tried again but the same failure: [root@metalica Db]#
    >>prostrct repair mfgsys mfgsys.st Database Repair: Unable to create
    >>lock file. (6928) [root@metalica Db]#
    >>[root@metalica Db]# date
    >>Wed Sep 17 10:28:29 EDT 2003
    >>[root@metalica Db]# ls -l *.lk
    >>-r--r--r-- 1 root root 38 Sep 17 10:26 mfgsys.lk
    >>[root@metalica Db]#
    >>
    >>
    >>

    >
    >
    > Hmm.. Progress support (http://esupport.progress.com) only has one issue
    > with this behavior on Linux:
    > Issue No: P17735
    > Cause: This is a known issue - the hostname must be less or equal to 28
    > character on Linux.
    >
    > What do the rest of the files look like??
    >
    > Kevin


    Kevin, you nailed it. The host name was metalica.derickssheetmetal.com which exceeded the 28 characters. I
    changed to metalica.dsmw-hmf.com, rebooted and the rebuild went without a hitch.

    I have numerous other problems that I'll tell Epicor to stop working this particular one to focus on those.

    Thanks for your help.



+ Reply to Thread