First of all, you probably want to restrict users who will be signing on via Webulator/400 to the applications that you have selected for their use. This means that the user should not be presented with a command line. The command line allows users to enter commands, including commands that you may not want them to execute - such as the CALL command to call a program, or STRPASTHR to access another system. At minimum, the SNDMSG command in the wrong user's hands can be a real nuisance. This includes the availability of the command line on some IBM provided displays. An operation as simple as the WRKJOB command (to allow the user to view and affect aspects of their individual job), while automated as part of a menu, still has a command line associated with it.
Inquiries and simple data entry that is run through a verification and authentication process are probably the best applications for global Internet access. These applications allow users the ability to view information about your company and its products, as well as enter limited information to order products or request more detailed inquiries. They also allow for the entry of order requests that can easily be followed up or verified after the fact.
If you have chosen to perform automatic sign on or user authentication sign on for the user, you probably do not want them to get back to a real AS/400 Sign On display. Access to the Sign On display defeats the work you have done in restricting access to the userid that you have defined for web access. It also gives the user the opportunity to begin "guessing" the userids and passwords on your system. As a result, it is best not to include an option to sign off from your menus (usually option 90) and application screens presented to the public. Keep in mind that this also includes the ability to sign off via help panels, whether they were written for your application or are supplied by IBM as generic help for the AS/400.
The inability to sign off presents us with a very reasonable question - How do I end the application and the job when the Webulator/400 session is closed by the user? Interestingly, the answer to that question is to issue the "SIGNOFF" command. This will not be available to the user, but from within the application when a screen or display error occurs - identifying that the session has been closed. Basically, you will monitor for errors whenever a screen is written to the 5250 display from your program. This can be done using MONMSG in CL programs following any SNDRCVF statements. The contents of the EXEC parameter would simply be the command "SIGNOFF". An illlustration of this procedure, as well as RPG and COBOL logic can be found in the following examples.
PGM DCLF FILE(DSPFILE) . . . SNDRCVF RCDFMT(SCREEN1) MONMSG MSG(CPF0000) EXEC(SIGNOFF) . . .
.....CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComment . . . C EXMFT SCREEN1 99 C *IN99 IFEQ '1' C MOVEL'SIGNOFF' SGNOFF 7 C Z-ADD7 SGNLEN 155 C CALL 'QCMDEXC' C PARM SGNOFF C PARM SGNLEN C END . . .
ENVIRONMENT DIVISION. . . . INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT DISPLAY-FILE ASSIGN TO WORKSTATION ORGANIZATION IS TRANSACTION FILE STATUS IS WS-FILE-STATUS. . . . DATA DIVISION. . . . WORKING-STORAGE SECTION. 01 WS-FILE-STATUS PIC X(2). 01 WS-SIGNOFF-VARIABLES. 05 WS-SIGNOFF-CMD PIC X(7) VALUE "SIGNOFF". 05 WS-SIGNOFF-LEN PIC 9(10)V9(5) COMP-3 VALUE 7. . . . PROCEDURE DIVISION. . . . WRITE DISP-RECORD FORMAT IS SCREEN1. READ DISPLAY-FILE. IF WS-FILE-STATUS IS NOT EQUAL "00" THEN CALL "QCMDEXC" USING WS-SIGNOFF-CMD WS-SIGNOFF-LEN, STOP RUN. . . .