Browse Prior Art Database

OS/2 Screen Groups for AS/400 PC Support

IP.com Disclosure Number: IPCOM000100169D
Original Publication Date: 1990-Mar-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 4 page(s) / 133K

Publishing Venue

IBM

Related People

Chia, KS: AUTHOR [+3]

Abstract

Described is a Work Station Feature (WSF) application programming interface (API) which provides a means of requesting WSF to load and execute programs. By passing pointers to parameter blocks from applications to WSF, WSF can call OS/2* to perform a LOAD and EXECUTE function. This causes a new program to be run using all the startup parameters from the caller. The result is that any application can be made to run as a child process of WSF and, in the same screen group, as WSF.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

OS/2 Screen Groups for AS/400 PC Support

       Described is a Work Station Feature (WSF) application
programming interface (API) which provides a means of requesting WSF
to load and execute programs.  By passing pointers to parameter
blocks from applications to WSF, WSF can call OS/2* to perform a LOAD
and EXECUTE function.  This causes a new program to be run using all
the startup parameters from the caller.  The result is that any
application can be made to run as a child process of WSF and, in the
same screen group, as WSF.

      This method is the way the load-and-execute function call
(DosExecPgm) is used in the WSF API.  The following primary parts are
involved, which are illustrated in Fig. 1:
      1.  WSF and Communications Manager (CM) and OS/2
      2.  Application's standalone startup program
      3.  Application program to be loaded by WSF

      As programs are loaded, the steps of processing are:
      1.  The user IPLs the PC with OS/2 and CM.
         a.  OS/2 is loaded normally.
         b.  Communications Manager (CM) is loaded, either
             manually or
             as part of a batch job or command file.
         c.  WSF is loaded, either manually from the Main Task Menu
or automatically using the auto-start configuration option.
         d.  WSF starts its sessions normally.
      2.  The user starts PCO, typically as part of the STARTPCS
command file.
         a.  The PCO startup program checks that WSF is loaded and
prepares parameter blocks for an OS/2 LoadExec function call.
         b.  The PCO startup program issues a WSF API command to load

      and execute a program passing the information necessary to load
and execute its application program.
         c.  Based on a good return code from WSF, the PCO startup
program will terminate quietly, leaving the PCO application program
resident in memory. Otherwise, it issues an error message and
terminates. AB:  Once the application portion of PCO has been started
as a child process of WSF, PCO can begin handling host commands that
start PC applications and manage the screen display in a seamless
fashion.

      Fig. 2 illustrates WSF sessions in the jumpkey loop and how
they relate to OS/2 sessions in the hotkey loop.  The applications
started by PCO will appear in the OS/2 hotkey sequence, and on the
OS/2 application selector panel.

      Fig. 2 also illustrates how screen groups are related in OS/2.
The OS/2 hotkey (alt-esc) or a selection from the switch list move
the user from one screen group to another. The WSF jumpkey (alt-pgup
or alt-F9 or other configured jumpkey) moves the user from one WSF
session to another in the WSF screen group.

      Block 1 is the Communications Manager of OS/2 EE, which is
always present while 5250 WSF is running.  Block 2 shows the DOS
compatibility box of OS/2, which is...