If the 5.005 program is reasonably well-written, it is likely to run under 5.8.1 without modification. The newer perl has more features, but is backward compatable with 5.005. At worst, 5.8 is a little more free with warnings.

That's no reason not to improve the program, it just lets you stop when you run out of time :)

After Compline,
Zaxo

Your reply intrigued me, so I changed the shebang line just to see what would happen. After a couple of changes ("EQ" to "eq", etc.), I get the following error message:

Can't call method "ct_execute" on an undefined value at /local/www/htdocs/scripts/pimgmt/nc_pf_58mainmenu.pl line 3717.

Here's the main script that calls various subroutines (notice no use strict; at this point in time but I'm hoping to change that once I dig in):

#!/usr/local/bin/perl5_8

use CGI;
use CGI ':standard';
use CGI::Carp qw(fatalsToBrowser);
use vars qw($CGI);
use Sybase::CTlib;
$CGI = new CGI();

# Get parameters based on login, etc.
  &get_parms($CGI);

# When global employee id ($g_empid) is blank, 
# initialization routines are bypassed and you drop out.

if    ( $g_empid eq "" )
      { &valid_user;
      }

# Clear the STDOUT buffers so MIME can get out; print html headers

$|=1;
print "content-type: text/html\n\n";

# Display Campus Main Menu and begin main processing

&main_process;
[download]

And here's the subroutine where the error message is generated:

sub valid_user()
{
# INITIALIZATION STEP 1:
# Check system availability 

  &set_db_env;
  $get_results=0;
  $sql = "select STATUS
               , MESSAGE
            FROM $g_pfsec_db.dbo.NC_PF_STATUS
         ";

  $db_avail= new Sybase::CTlib $g_pfsecid,$g_pfsecpw,$g_pfsecsrv;

  $db_avail->ct_execute($sql) ;     <====THIS IS LINE 3717

  while ( $db_avail->ct_results($restype) == CS_SUCCEED )
        {

          next unless $db_avail->ct_fetchable($restype);

          while ( ($dbf_STATUS, $dbf_MESSAGE) = $db_avail->ct_fetch )
                {
                  $get_results++;
                  $app_status = "$dbf_STATUS";
                  if    ( $dbf_STATUS eq "U" )
                        {  $|=1;
                           print "content-type: text/html\n\n";
                           &top_hdrs;
                           &display_msg($dbf_MESSAGE);
                           exit;
                        }
                }
[download]

So, I dug around here for some answers... and have read a lot (the rods and cones in my eyes are going nuts staring at a white screen for so long). I'm getting the impression the database doesn't like how I'm speaking to it, but that's only a guess. Do I need to tweak something because of the new version of Perl? Thanks for any help you can provide! Lori

That sounds like Sybase::CTlib is not yet installed for perl 5.8.

Update: The names of the functions might change, but I wouldn't expect it outside a major version change. The default exports might change, though. I don't use Sybase, can't advise on that. Try checking all your db calls for errors. The messages may clarify the problem, and that is an excellent improvement for your rewrite.

After Compline,
Zaxo

It sure looks as if $db_avail= new Sybase::CTlib $g_pfsecid,$g_pfsecpw,$g_pfsecsrv failed and as $db_avail now does not contain a valid reference to an object, $db_avail->ct_execute($sql) gives you this error. So it seems Sybase::CTlib is loaded but does not work.

This may or not may be due to the fact that Sybperl (of which Sybase::CTlib is/was a part) is not ported to all systems.

M. Peppler, author of Sybperl, writes on his website:

Note: Recent versions of ActiveState (perl 5.8.x) don't offer PPMs for sybperl or DBD::Sybase any more. As a replacement there is a PPM repository maintained by perlmonk's "crazyinsomniac" at http://crazyinsomniac.perlmonks.org/perl/ppm/. I have not used these packages, so I can't comment on how well they work.

Could it perhaps be that an old version of Sybperl was installed? A search on CPAN showed no hits for Sybase::CTlib anymore (except Apache::Sybase::CTlib), not even in the Sybperl distribution.

I suggest you contact the author of Sybperl and ask for his comments.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Once you have a test suite, validating your code on the new version of perl becomes a *lot* easier.

The consultant didn't create any test suites, and there's only a little documentation in the form of comment lines. I've contacted the consultant and it seems he's in almost the same position I'm in now... being very new to Perl and having to grab code from other Perlers, even if he doesn't completely understand how it works. I'm finding my confidence level isn't very high in my ability to completely re-write the code from scratch, especially since it's a little complex (at least to me!).

Not documenting is a terrible sin, especially for someone who is being paid a great deal of money and who is not going to hang around to perform the needed maintenance. However, divining what the code does and writing the documentation will certainly be a worthwhile learning experience. If you can find the original requirements documents and specifications (assuming they exist!) they should make the job easier.

As for the confidence thing - at least you can feel superior in making use of community resources and Doing The Job Right when compared to that overpaid underperforming wastrel of a consultant :-)

Slightly off topic but I have to get this off my chest. When hiring a contractor to produce code, of any kind, stipulate that they must provide clear documentation in order to complete the contract. Get it in writing.

Neil Watson
watson-wilson.ca

I need to create a handful of other new reports (with all the variations/flavors/details they might need) in our current database. Then, I'll need to upgrade that script to run against our new database once it's migrated from Sybase to Oracle, and from an old version of PeopleSoft to a new version of PeopleSoft.

I think your fear of rewriting from scratch is quite good. Since you have new development work to do, now is a great time to start writing tests. I wouldn't write tests for the whole system, just the parts you touch. When you've tested an individual piece sufficiently, take a few minutes to clean it up.

If the important parts of the program are in the bit that creates reports, you'll have tested and cleaned the most important parts of the program once you're done. With those tests in place, it'll be much easier to port the program to Perl 5.8.

You can find more information in Five Lessons You Should Learn From Extreme Programming and Five Lessons Open Source Developers Should Learn From Extreme Programming.

Lori713 - You need to rewrite the system. You could shoehorn the old system in with the new back-ends, but it would be very risky. This is compounded by the fact that you have no test-suite.

I'd rewrite it using Test-Driven Development methods. Write the test, have it fail, then write the code that makes that test pass. Lather, rinse, repeat. There are a number of nodes regarding TDD on Perlmonks and other venues. It makes things very simple for a newer developer because you're focusing on results, not methods. Also, if you ever want to change something, you have a test-suite that describes what this thing is supposed to do. :-)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.