1). This will get you back in by resetting your username and password. Download this file (if you cannot download it, create a file named adminpass1.file and enter the text you see when you click on the download link. The username and password are separated by a tab, not spaces). Then upload it to the following directory on your server :

/psjs_datalogs/[scriptname][$FolderPass]

where [scriptname] is the name of the script you purchased and [$FolderPass] is the variable you set (or was set for you) in either the _cfg.cgi or _key.cgi file. You should recognize the folder when you see it. In it, you will see a file named adminpass.file. It contains your username and encrypted password. View it, looking at the username may jog your memory. The password is encrypted so that won't be much help. If you still can't remember, upload the file named adminpass1.file so it's in the same directory as adminpass.file. Then rename it adminpass1.file to adminpass.file so that it overwrites the original adminpass.file. This renaming method is used because there are sometimes permission problems when you attempt to upload and overwrite in one action.

Once the file has been overwritten, your new username and password will be :

Username : 111111
Password : 111111

2). Your second option is to re-run the _setup.cgi your received when you purchased your scripts. If you still have a copy of it, upload it to your server in ASCII mode and then CHMOD it to 755. Load it in your browser and follow the prompts. The set up file will NOT overwrite any of your data files except of course the username and encrypted password file.

There are two groups of files that need to be transferred, in some cases (Build a FAQ) three groups.

Group 1

The CGI scripts. These must be transferred in ASCII mode to any CGI executable folder on the new server and then CHMOD (have their permissions set) to 755, as per a normal installation.

Group 2

The data files. These are located in the /psjs_datalogs directory which is located at the root of your web space (your home directory or the directory your home page resides in). Inside the /psjs_datalogs folder, you will find one or more sub-folders. Each folder inside the /psjs_datalogs folder is dedicated to one of our scripts. These sub-folders are named using an acronym for the scripts, followed by the $FolderPass variable which is set in the _key.cgi file. For example, if you purchased Attachment Mailer Plus, you'll have a CGI file named amp_key.cgi. Inside amp_key.cgi you'll find a variable named $FolderPass.

$FolderPass = "1111222234";

So you'd have a folder inside the /psjs_datalogs folder named:

/amp1111222234

Transfer, in ASCII mode, the entire /psjs_datalogs folder and all of it's sub-folder and files to the new server. CHMOD all of these to 777 on the new server.

Ensure that the $FolderPass in the _key.cgi script on the new server matches the sub-folder name you transferred. If they do not match, you'll not be able to log in to the Admin section, as the scripts will not be able to find your data files which include your encrypted password for log in.

In most cases, that is all that's necessary. In some cases, especially with scripts that perform file uploads, you'll need to update the paths to your File upload directory (often defined in the Web Admin settings) so that they match the new server's path. You can ask your host for the correct path, or you could download and install E-Vars from our download page to try to determine the correct path.

Group 3

If transferring Build a FAQ, you'll also need to transfer the folder you have defined as the folder to store your static FAQ pages. The default is /ourfaqs located in your home directory. This folder and it's contents should also be transferred in ASCII mode and CHMOD to 777 on the new server.

If transferring Upload Gold or Upload Pro, you need to transfer the File upload folder you have defined in the Web Admin settings. This folder and all of it's content should also be CHMOD to 777.

I need help. Often, you may be better off install a fresh copy of the scripts. If you need to retain the data files, and cannot complete the transfer successfully, you'll now need to Order installation. We'll do our best to install and retain all data, and of course only charge if successful. The standard installation fee applies for standard transfer and set ups. If you have a large amount of data which you require us to also transfer, additional fees will apply.

For over 6 years, Customers whose servers do not permit unlimited data transfers, have written to us under the false impression that the problem lies within the Perl Script they purchased. For over 6 years, we've repeatedly written back to Customers insisting the problem lies with the Server and it's limitations imposed by the Host Provider. And we can honestly say, that when the Customer says something to the effect of "I can upload files smaller than XX MegaBytes, but cannot upload files larger than XX Megabytes", the problem has been with the server each and every time.

You'd think that after 6 years, we'd create a canned response. Well guess what? We have, and this is it. Here to enlighten not only you, but in some cases the Host Provider also.

You see, our scripts can theoretically transfer files larger than your hard drive, larger than your web server's hard drive and larger than the Internet itself. That's pretty large in anyone's book. Theoretically, as long as a connection between the client (the computer uploading the file) and the server (the computer receiving the file) is present, and the server's hard drive (or receiving folder) has the capacity to store the file, there is no limit to the size of the transfer unless you yourself specify one within the script.

The problem is in the server limits imposed by the Host Provider. These are limits consciously set on shared servers by your Host Provider to ensure one single process does not utilize all of the server's available resources, which would adversely effect all other websites hosted on the same server.

The three main reasons why a file upload or transfer would fail are :

1. Post Max limit
2. Uploads disabled
3. Timeout setting

1. Post Max Limit

All of our Upload scripts utilize the CGI Perl Module (CGI.pm). This can be found at CPAN

The CGI Perl Module is resident on all servers that have Perl installed. It enables the Host Provider to limit the number of bytes (the data) that can be Posted by any Form. It works by reading the total size of the data being transmitted by Forms using the Post Method including the size of any files selected. The Post Method is required for large data transfers, because the Get Method (the method of transmitting data in the URL) is often limited by Web Browsers to a size insufficient to transfer even a small image file such as a company logo. If the data size exceeds the defined value in the CGI Perl Module, the transfer will fail with the error message "413 Request entity too large" returned by the CGI Perl Module. However, according to the author of the CGI Perl Module "it isn't clear that any browser currently knows what to do with this status code".

You cannot change the CGI Perl Module's $POST_MAX variable unless you have root access to the server. The Module is installed in the Common Perl Library folder well above a website's web space, so the one copy can support all websites. If you do not have root access to the server, you must write to the Host Provider and ask that they check this, and if required, increase it also.

2. Uploads disabled

The CGI Perl Module can also flatly deny all file transfers. It will however process the Form's other fields as normal. As with the Post Max Limit, unless you have root access to the server, you cannot alter this Setting.

3. Timeout setting

Each server also has a configuration file which enables the Host Provider to set a process Timeout. That is, each request made to the server, be it a request for a Web Page, a request for a file or a request for a server side script (such a Perl script capable of transmitting multipart form data or file uploads), can be limited to XX seconds. The default Timeout setting is often 300 seconds. Unfortunately, this setting is also often left unchanged. In this case, if you're attempting to upload a file which would require a transit time greater than 300 seconds, the server would terminate the process prior to it's completion resulting in a "Server 500" error or a "This page cannot be displayed" error. This makes sense, because the server returned nothing back to the Browser for it to display. The communication between the client and the server side script was severed.

You cannot change the Timeout setting unless you have root access to the server. The Timeout setting is found in the server's configuration file which can reside anywhere on the server, but is often found in the /etc/httpd/conf folder in a file named httpd.conf

In summary, contact your host, as we cannot help you. Your host controls the server and what it's prepared to accept. Point your host to this page if you like, because often they will disregard your request for help for various reasons including the belief that the problem lies within the script. This is justifiable, as we've seen many shoddy scripts on the Internet written by novice programmers who often have good intentions, but lack the experience required to develop software for the open market.

$FolderPass = "jjkknew1qw";

You must make sure that the $FolderPass in the new script matches the $FolderPass in your original copy. This is so the data files can be found. This change will only be necessary if we send you the _cfg.cgi file as part of the update.

After making sure the $FolderPass variable matches, upload and overwrite your existing scripts. Then refresh your admin page and you're done.

If we sent you the _admin.cgi or [script].cgi scripts, without the _cfg.cgi scripts, you do not need to make any edits. Just upload and overwrite your existing files.

Our scripts use session cookies to identify the user logged in and as a security measure to ensure the cookie set matches the password on record.

To enable session cookies in...

Opera 5

File - > Preferences -> Privacy

Netscape 4

Edit -> Preferences -> Advanced

Netscape 6

Edit -> Preferences -> ( Double click ) Privacy and Security -> Cookies

Internet Explorer 4

View - > Internet Options -> Advanced -> Cookies

Internet Explorer 5

Tools - > Internet Options -> Security -> Internet -> Custom Level -> Cookies

Internet Explorer 6

Tools - > Internet Options -> Privacy -> Advanced or Edit

You need to create a .htaccess file and place it in the directory you want to execute scripts in. Inside the .htaccess file enter the following two apache directives :

AddHandler cgi-script .cgi

Options Includes ExecCGI

If you already have a .htaccess file in the directory, edit it and place the two directives at the top. If the above fails to execute scripts in the directory, your server's httpd.conf file probably has something like this :

AllowOverride All

Order deny,allow Deny from all

In this case, you'll need to either contact the server admin or modify your server's httpd.conf file if you have permission. It's usually located well above your web space in a directory called : /etc

You may see something like :

Set-Cookie: un=username; Set-Cookie: pass=OY6jdhGw7TM;

That is the script requesting two session cookies. Normally you would not see that because it's printed before the output stream is sent to the browser. However, when the server starts the output stream prematurely (with the Content-type header), it's too late to set cookies.