WebReport/400 Frequently Asked Questions

Index:

• Do I have to use MetroFax for WebReport/400's new fax output feature?
  
• WebReport/400 automatic routing is not working following a power failure, what can we do?
  
• Does the special user profile WEBBREPTUSR require *SECOFR and *SECADM authority?
  
• Is WebReport/400 ready for IBM i OS 6.1?
  
• How can I install WebReport/400 on a disaster recovery system for backup testing?
  
• We are upgrading our version of OS/400 (i5/OS), are there any special considerations for WebReport/400?
  
• Release 6 supports color AFP overlays, how can I create a color overlay for use with WebReport/400?
  
• I would like to start using overlays with our spool files but we have no experience with this. How do I create an AFP overlay?
  
• Can I use my iSeries-AS/400 as my outbound mail server?
  
• I am using the AS/400 to send mail, how can I control SMTP message relaying?
  
• How can I trace what is happening with outbound Email on my system?
  
• I notice some SMTP server jobs that seem to be stuck in a loop trying to send E-mail to bad destination addresses, is there a way to stop this?
  
• Email reports from WebReport/400 arrive showing the wrong time of day, how can I correct this?
  
• WebReport/400 places HTML documents in source files or in shared folder files, but I need to place them into the IFS (Integrated File Sysytem). How can I use WebReport/400 to do this?
  

When getting WebReport/400 ready to support fax output through an Internet fax service, we researched several companys and settled on MetroFax because of service and price. We thoroughly tested this service and made sure that WebReport/400 could send a properly formatted fax of a standard 132x66 computer report through this service.

This does not mean that other Internet fax services will not work. We have just heard from another WebReport/400 customer that they have been successful with sending faxes using the RapidFax service. Others may also work well and we encourage you to test each alternative. This can be very helpful if you are using WebReport/400 outside of the USA or Canada.

The automatic routing function in WebReport/400 depends on a data queue object named WEBRTR in library WEBREPORT. Sometimes, a data queue can be damaged during an unscheduled system failure, such as a power failure.

Do determine if your data queue is damaged, try shutting down the WEBRTR job in the EREPORT subsystem using the normal method of option #16 from the MASTER menu in library WEBREPORT. If it fails to shut down right away, then the data queue is damaged.

To fix the data queue, you will have to manually end (cancel) the EREPORT subsystem. Wait until it is stopped, then manually delete the data queue in library WEBREPORT named WEBRTR using the following command:

DLTDTAQ DTAQ(WEBREPORT/WEBRTR)

CRTDTAQ DTAQ(WEBREPORT/WEBRTR) MAXLEN(128)

When you install WebReport/400, the install instructions require that you first create a special user profile on your system called WEBREPTUSR. The instructions call for all special authorities to be assigned to this profile. Some customers have questioned why the profile must have security officer features activated. The reason for this is that the application uses some commands internally that require this authority. If you need more specific information about this, please ask us. To improve security, this profile can be set up with a password of *NONE and it can be maintained in *DISABLED status.

All levels of WebReport/400 Release 9 have been confirmed as ready to upgrade to the new IBM i OS Release 6.1 (V6R1). If you run the OS Analyze Object Conversion (ANZOBJCVN) command for the WEBREPORT library, you may see one *PGM object named GN#HLP that will report as being not ready. This object is from a third party supplier and is not required for normal operation of the software. We are working on getting this single object updated, but you do not need this object for normal operations.

Contact us by email at the link near the top of this page if you have further questions about i OS 6.1 compatibility.

To install WebReport/400 on your backup system for a disaster recovery situation, either a test or an actual recovery process, do the following:

1. Save the library named WEBREPORT from your production installed system using the SAVLIB command.
2. On the recovery system, sign on as a security officer for the rest of these operations.
3. Check to make sure that the special user profile WEBREPTUSR has been created on the target system. If you have restored the user profiles from your primary system, it should be there. If you are doing a different type of recovery, make sure this profile is created before you continue to the next step.
4. Restore the WEBREPORT library on your recovery system using the RSTLIB command.
5. Go to the INSTALL menu in library WEBREPORT.
6. Run option #1.
7. At this point, the software will be active on this system for a 30 day period. If this is an actual disaster recovery event, contact Kisco Information Systems for additional information about keeping WebReport/400 active on this system for the duration of your event.
8. You will have to set up the TCP/IP environment on your backup system before you can use the email features of WebReport/400. See the WebReport/400 documentation for more details about configuration.

As of this writing, we have never experienced any issues with WebReport/400 when moving from one version of the installed operating system to another. We do recommend, however, that you make a complete listing of all of your TCP/IP settings just in case any of them get changed during the OS upgrade process.

If you have never created an AFP overlay before, please read the following topic before you tackle this one. We recommend that you have AFP overlay creation and use under your belt before attempting to work with color overlays.

Note: The following procedure only appears to work when you use a PC that is running Windows XP. Tests on Win98 and Win2k show that the color tabs in the driver do not come active. You must use a PC running WinXP.

To create a color overlay, use these instructions:

1. Download and install the latest IBM AFP printer driver. Try this link: http://www-1.ibm.com/support/dlsearch.wss?rs=95&apar=exclude&q=afp++printer+windows+driver&dc=D430

2. Install an IBM printer which supports color printing. Try the 3935 definition which appears to create good results.

3. Open the printer Properties, and click on the General tab and then on the Printing Preferences button. Make sure Output type is set to "Overlay".

4. Next, click on Image options, then Properties. Make sure the Color options are set to Full Color, and the compression to JPEG. It won't currently work with any other settings.

5. Now click on the Ports tab and select "Print to file".

6. Now you should be able to design a document in, say, Word, print to this file and it will prompt you for a file name e.g. testovl.prn.

7. On the AS/400, create a file for the overlay data, e.g. CRTPF OVERLAYS RCDLEN(32766) MAXMBRS(*NOMAX) LVLCHECK(*NO)

8. FTP the file created earlier on the PC to this file, e.g.

   bin
   put testovl.prn overlays.testovl

9. Create the overlay, e.g. CRTOVL TESTOVL FILE(OVERLAYS) MBR(TESTOVL)

If you need help with this, or if you would like to contract with Kisco Information Systems to create your overlays for you, please contact us.

Creating an AFP overlay is not all that difficult. It is done on a PC that is attached to your system. You have to download an AFP print driver from IBM, then install and configure it. (On more recent releases of OS/400, this print driver is included on the Client Access/400 install CD.) Once this is done, you then design your overlay on the PC using a graphics program or any standard wordprocessing software (we normally do our overlays in Word or WordPerfect as we find it easier than dealing with the graphics software). Then, once the overlay is ready, you just print it using the new print driver. This creates a file on the PC that you need to transfer to your iSeries-AS/400 and process through a conversion command that is a part of OS/400.

There is a discussion available at the IBM support site that will fill in the blanks to this brief description. Just click here to see the writeup.

If you need help with this, or if you would like to contract with Kisco Information Systems to create your overlays for you, please contact us.

In a word - YES!

Many customers have asked how to set this up and it is really quite simple. The only pre-requisite is that your system must have a direct route to the Internet. If you have configured WebReport/400 already, then you already have the Mail Server Framework and the OS/400 SMTP functions configured. The only thing you have to add to this mix is the OS/400 POP server (Post Office Protocol) and you will need to make a configuration change to your SMTP server setup.

Here's what you'll need to do:

1. Type the CHGPOPA (Change POP Attributes) command and press F4 to prompt the command. Make sure the first parameter, "Autostart servers", is set to *YES. Then press ENTER to record the change.

2. Type the CHGSMTPA (Change SMTP Attributes) command and press F4 to prompt the command. Use the Roll-Up key once to display the second panel, then change the "Mail Router" parameter to point to the IP address of your iSeries-AS/400 system. You should make a note of the field contents BEFORE you make the change, just in case you have to set this back in the future. Press ENTER to record the change.

3. At this point, you will need to process the following commands to shut down your current email environment.

   ENDTCPSVR *SMTP
   ENDTCPSVR *POP

4. Now, restart your email environment with the following sequence of commands:

   STRTCPSVR *SMTP
   STRTCPSVR *POP

At this point, your iSeries-AS/400 system will be your outbound mail server for WebReport/400 and any/all other SMTP-based applications running on your system.

Important Note: If you are just starting to use your system for outbound mail, you should set the system up to prevent spammers from relaying mail through your iSeries-AS/400 system. Read the following topic on how to configure for this issue. Failure to do so could result in your system appearing on an Internet blacklist, which could prevent some or all of your mail from being properly delivered.

Controlling SMTP mail relay involves two processes. First, you have to set the ALWRLY parameter in the SMTP Attributes on your SMTP server. This is updated using the CHGSMTPA (Change SMTP Attributes) command.

If you just want to deny all mail relays, set this value to *NONE and you’re all set, you can stop reading now and move on with your life. However, this will also stop WebReport/400 from working. Simply changing this setting to *ALL is not a good idea either as this will allow anyone to relay mail through your system. The best choice for WebReport/400 use is the value *LIST. This will restrict email relays to only those IP addresses that you specifically authorize.

Once you have relaying configured and have specified the *LIST setting, you will then have to update the SMTP list to indicate who can relay mail. This is done using the ADDSMTPLE (Add SMTP List Entry) command. There are a lot of options for this, but as a simple example let’s set up an entry that will permit mail to be relayed from your iSeries-AS/400. If your system has an IP address of 10.100.2.1, then you would add a relay accept transaction that looks like the following:

ADDSMTPLE TYPE(*ACCEPT) INTNETADR('10.100.2.1')
SUBNETMASK('255.255.255.255')

After you get these changes made, you should end and then restart your SMTP server before testing for the results. Ending the SMTP server is done with the following command:

ENDTCPSVR SERVER(*SMTP)

STRTCPSVR SERVER(*SMTP)

We are often asked how mail can be traced on the AS/400 when things appear to be configured correctly but the mail is just not going out. We have discovered that OS/400 includes a journaling feature for SMTP that you can activate using the following procedure. Journaling adds overhead to processing on your system, so we recommend that once you activate it, that you go back and deactivate it once you have traced your problem.

To set up SMTP journaling and look at the journal information:

1. Change the SMTP attributes by keying the command CHGSMTPA and pressing the F4 key to prompt it.
2. Roll up to the second panel and change the "Journal" parameter to *YES.
3. Use WebReport/400 to send a report via Email.
4. On an AS/400 command line, enter the command: ADDLIBLE QTCP
5. Enter the command:
   

   DSPJRN JRN(QZMF) OUTPUT(*OUTFILE) OUTFILE(QUSRSYS/ZMFSTUFF)
   OUTMBR(MAR2) ENTDTALEN(512)

6. To view the SMTP journal, type the following command:
   

   DSPPFM FILE(QUSRSYS/ZMFSTUFF) MBR(MAR2)

7. Press F20 to see the journal-specific information

According to information found at the IBM support website, the SMTP server can be set to destroy distributions that it cannot process. How SMTP does this depends on the existence and contents of a single-character, user-defined data area called QTMSCLEAN in the QUSRSYS library. The character in this data area indicates the extent of mail control block clean-up:

• An uppercase or lowercase c in this data area indicates a cold start was requested to free all mail control blocks.
• Any other character causes a warm start to free only the first floater mail control block found. A floater is an MCB that was dequeued but was not fully processed or failed processing when SMTP ended (for whatever reason).

Since a warm start frees only a single MCB, it may be necessary to stop SMTP, create the data area, and start SMTP more than one time to get to the MCB that is causing the problem. If there are a large number of MCBs, a cold start may be the fastest way to correct the problem.

To create the QTMSCLEAN data area, use the Create Data Area (CRTDTAARA) command as follows:

CRTDTAARA DTAARA(QUSRSYS/QTMSCLEAN) TYPE(*CHAR) +

     LEN(1) VALUE('X') AUT(*ALL) 

On the AS/400, there is a system value that controls the time shown on Email messages sent by WebReport/400. The system value is named QUTCOFFSET and it contains the Coordinated Universal Time Offet value. As shipped from the factory, this is set to zero so all Emails are time stamped as if you were located in Greenwich, England (as in Greenwich mean time).

To adjust this value to work correctly on your system, change it to reflect the difference in time between where you are located and Greenwich Mean Time. For US customers, Eastern Time would result in a value setting of -05:00. For Pacific Time, the offset value should be -08:00, and so on for other time zones.

On newer versions of the System i operating system, starting with V5R3 and later, you cannot change the QUTCOFFSET value directly. On these systems, there is a system value named QTIMZON that contains a setting that describes the time zone where your system is located. Use this setting to adjust the time for your outbound email messages.

Beginning with WebReport/400 Release 4.01, this function is supported directly from the WREPORT command. If you have an earlier version of WebReport/400 installed, use the following instructions:

WebReport/400 can be used to convert your report into HTML. You can then execute a simple CL command to move that converted HTML file into the IFS on your system. The CL command will also take care of EBCDIC to ASCII conversion.

First, process the report to a source physical file. There is a source file in library WEBREPORT named WEBSRC that you can use for this.

Then, process the following command to move the source member to the IFS converting it to ASCII code in the process. This example assumes that you are using the above mentioned source file with a member named REPORT1. The example then assumes that you want to move the report to a directory name WEB under your HOME directory in the IFS with a file name of REPORT1.HTM.

CPYTOSTMF FROMMBR( qsys.lib/webreport.lib/websrc.file/report1.mbr') +

 TOSTMF( /home/web/report1.htm') DBFCCSID(37) STMFCODPAG(437)

Phone: (518) 897-5002 Fax: (518) 897-5003

E-mail your questions or suggestions: Support@Kisco.com