There are four alternatives for people who do not have one of the supported platforms (see the table in See Available RPS2 configurations for supported platforms). Please refer to the table below:
Any XWindows display device with TCP/IP (the Internet Protocol) may be used to display the interactive version of RPS2. The display device does not need to be a Sun; any XWindows client will work. (Some examples are: non-Sun Unix workstations, XTerminals, personal computers running XWindow emulation software, and VAX workstations.) In each case, four steps are necessary:
You can skip the step of setting the DISPLAY variable by using the command line option for setting display at the time you invoke RSP2:
If you have Internet access but do not have access to a suitable graphics terminal which can display XWindows, your Program Coordinator will assist you in obtaining a special account on an STScI computer. You can then run the command-line version of RPS2 (but not PED) by following these steps:
Once you have completed the first draft of your proposal, use telnet or rlogin to login remotely to your STScI account. Then use a transfer protocol (such as FTP or Kermit) o copy your proposal from your home computer to your STScI account. Remember to create a separate subdirectory for your proposal and use the file name: <#>.prop , where <#> is the proposal ID number supplied by your PC.
Type the following command while in the directory which contains your draft proposal:
(There is a blank, two dashes, and a blank between "rps2-com" and "process.")
This command combines two of the interactive RPS2 commands: "Process" and "Write PS Files." You will see status information scroll by on your terminal screen. When processing is finished, a complete set of PostScript files will be available in the proposal directory. These files will contain the Proposal Summary Report, Visit Summary Reports for each visit, diagnostic reports for each visit, and the concatenated help file. These are the same files that would have been created had you been running the interactive version of RPS2 and used the "Write PS Files" option.
In order to look at these PostScript reports, you will need to transfer all the . ps files back to your home machine and print them on a PostScript printer.
Once you have worked out all the details of your proposal, use the command line version of RPS2 to submit your proposal to STScI. You may want to compose a comments file. Use this file to submit feedback or comments with your submission. Put the completed version of the proposal (and the comments file if you wrote one) together in one directory on your STScI account. Then issue the following command:
(Again, there is a blank, two dashes, and a blank between "rps2-com" and "submit.")
As with the "Submit" option in the interactive RPS2, the submission software returns an automatic electronic acknowledgement to you via e-mail.
If you have RPS2 installed on a system at work but want to work from a non-graphical terminal at home (or in your office), you can use the command line version of RPS2 as outlined in See How to run the command line version of RPS2 If you do not have a PostScript printer at home, you can at least review the Syntax diagnostics on-line by reading the raw *.p*-diag files. If you have not run the graphical RPS2 interface first (and therefore have not started the servers), you may want to start the servers on your work system to avoid the internet connection to servers at STScI.
The servers are started by typing:
This will start all server processes. This will also create log files in your current directory (each with the extension .log ). As long as the servers are running, the RPS2 client will be able to use the local servers instead of the ones running at STScI.
To shut down the RPS2 servers on a local machine type:
The command is available as a convenience and not a necessity. Normally there is no reason to shut down the servers, since they consume minimal resources when they are not being used. Remember that if the local servers are stopped, RPS2 will run, but it will be accessing the heavily loaded STScI servers generally resulting in slower response.