System 1032
DECwindows Rediscovered By Tym Stegner
Over the past several weeks I revived my acquaintance with DECwindows, while working with ODBC on a VMS V7.2-2 system. I tried the DECwindows interface for System 1032 and am pleased to report that it works in this environment. This article is to encourage you to take advantage of this interface yourself.
Reintroducing DECwindows DECwindows/MOTIF is the OpenVMS windowing component. If it is installed on your system and you have the suitable privileges, you can send displays and applications to other systems, or to other terminals, or to PCs supporting X-Windows.
The Using DECwindows/MOTIF on OpenVMS manual, available at the HP OpenVMS Documentation, introduces DECwindows as:
“DECwindows lets you divide your workstation screen into windows and design your own working environment. Using DECwindows, you can run multiple applications simultaneously on a single screen and switch between them. This means that you can run a program in one window, read a mail message in a second window, and write a memo in a third.”
DECwindows operates within a client/server environment that is best described in the Managing DECwindows/MOTIF for OpenVMS Systems manual:
“DECwindows Motif for OpenVMS software operates on a client/server model. A server is a single-shared process that performs operations at the request of many client processes. In the DECwindows Motif environment, the graphics applications--such as DECterm and DECwindows Mail (or System 1032!)--are the clients that interact with the display server. The display server manages the physical graphics display and input devices on behalf of the client applications.”
Checking for DECwindows To find out if your system has DECwindows in operation, issue a SHOW SYSTEM command. Look for the DECwindows server process named DECW$SERVER_n.
$ SHOW SYSTEMOpenVMS V7.2-2 on node VMSTST 29-JAN-2004 15:31:20.50 Uptime 1 22:18:41 Pid Process Name State Pri I/O CPU Page flts Pages00000201 SWAPPER HIB 16 0 0 00:00:00.08 0 000000204 LANACP HIB 13 59 0 00:00:00.03 108 14400000207 ERRFMT HIB 8 5310 0 00:00:01.09 98 11400000209 OPCOM HIB 8 539 0 00:00:00.05 121 430000020A AUDIT_SERVER HIB 10 81 0 00:00:00.02 153 1470000020B JOB_CONTROL HIB 10 2340 0 00:00:00.07 49 6900000211 DECW$SERVER_0 HIB 6 2078 0 03:14:18.91 4143 41700000212 DTSESSION LEF 4 24884 0 00:00:05.44 1180 66800000216 DTWM LEF 6 151446 0 00:00:48.38 782 727 S000004D9 Tym CUR 4 44465 0 00:00:07.70 12872 123000004E6 MULTINET_SERVER LEF 4 1337 0 00:00:00.12 391 1850000052F SYSTEM_1 COM 2 164 0 00:02:55.95 456 187 S0000035C _FTA1: LEF 8 1230 0 00:00:00.35 1556 67$
Establishing a DECwindows Environment If you work at a terminal, it must be one that supports the graphics necessary to display the graphical windows. If you work at a PC, you must install software that acts as an X-windows server, such as the Hummingbird Connectivity Suite, containing the Exceed X server for Win 32. Another commonly used package is the Excursion software.
I work at a PC, so I ensure that Exceed is started before continuing. There is no on-screen evidence of its operation, unless I have its command bar on display. However, its icon in the Start bar indicates it is in operation.
With the X-window server in operation, you can setup for the client operation. From your TELNET window on your PC, enter a command to create a display instance for the PC:
$ SET DISPLAY/CREATE - $_ /TRANSPORT= DECNET | TCPIP | LOCAL - $_ /NODE=network-PC-name | IP-address
Then issue a SHOW DISPLAY command to verify that your process now has a display available:
$ SHOW DISPLAY %DECW-W-OPENIN, error opening DECW$DISPLAY as input -SYSTEM-W-NOSUCHDEV, no such device available $ SET DISPLAY/CREATE/TRANSPORT=TCPIP/NODE=PC030201 $ SHOW DISPLAY
Device: WSA42: [super] Node: PC030201 Transport: TCPIP Server: 0 Screen: 0
$
The final step is to start the client application--in this case, the System 1032 session. The Line mode interface has no DECwindows component, so you must start System 1032 in Command Window mode. When initializing Command Window mode, if a DECwindows device is detected, the DECwindows interface is launched instead of the character-cell interface.
$ S1032 let $cmd_mode = “window”
Using DECwindows As the following screen capture demonstrates, two new windows are created upon my display, one each for the input and output windows:
Once created, you can resize and customize the windows as you wish. This provides additional means of capturing command entry, as well as capturing report output, to be cut-and-pasted elsewhere.
Closing DECwindows To close the windows, exit from System 1032 as usual. The windows are dismissed, and you are returned to your TELNET session. If there is no further need for the window capability, you can close the display device using the SET DISPLAY/DELETE command:
$ SET DISPLAY/DELETE $ SHOW DISPLAY %DECW-W-OPENIN, error opening DECW$DISPLAY as input -SYSTEM-W-NOSUCHDEV, no such device available $
If the X-server is no longer required, you can close it as well.
Creating a Windows-base User Interface for System 1032 Windows Toolkit is available from CCA for users who want to create their own user interfaces to System 1032 applications. The Windows Toolkit is a set of software utilities that let you develop System 1032 applications that run on an X-based workstation (or X-enabled PC). Using Windows Toolkit you can write applications in PL1032 that incorporate sophisticated graphical user interfaces into your System 1032 applications. You do not need to use or know the C programming language to write these applications.
See “The X Windows Workstation” in the System 1032 User’s Guide, Module 2, pages 7-9 for additional information about using the Command Window under X Windows.
Windows Toolkit software is available on the System 1032 consolidated distribution CD, as of the V980 release. The System 1032 Windows Toolkit Guide is also available upon request. The Windows Toolkit is provided As-Is and is not supported.
In Summary This article demonstrates another interface available for the System 1032 database management system. Users, who have the necessary software, may appreciate the windows interface, so as to coincide with the user interface of other applications.
Spring Semester Beckons From the CCA teaching staff
A new hire or an old hand might benefit from a course in system management, file management, or programming for your favorite database. Classes are taught in the CCA classroom in Framingham or at your site. Have a look at the Spring teaching schedule. If none of the classes quite fit your needs, call to make arrangements for an instructor to come to you.
NonStop/204 Extending 24*7 Capabilities - Part 1 By James Damon
One of the many tasks performed by a Model 204 DBA is that of taking reliable backups. The frequency of backups is determined by the importance of the data and the level of update activity. Site requirements may dictate that mission critical databases be backed up daily. Other databases, though also mission critical, may have only weekly or monthly backup requirements if the level of update activity is low.
Whatever the frequency, the DBA must then decide when (time of day) and by what method (native Model 204 or third-party utilities) backups should be taken. If backups must be taken during prime-production periods, when files are opened for read and update and subsystems are active, then the Model 204 DUMP command is required. This command guarantees that a backup taken, even while a file is being updated, will be a logically and physically consistent copy of the file as of the time the dump started.
However, when many files or large files must be backed up, the time available for backups becomes a critical factor and the use of high-speed, third-party utilities such as DFDSS, FDR, IDCAMS, IEBGENER, SnapShot Copy and others may be required. Prior to NonStop/204, these utilities could only be used to backup files that were closed and not in use by any Model 204 system.
Introducing NonStop/204 NonStop/204, introduced in V5R1, reduces the period of time that a file is unavailable while taking file backups using third-party utilities. Now these backups can occur while files are opened for read or update, while subsystems are running, and while users are accessing data. The system manager establishes an extended quiesce in the Online during which file backups may occur. During this period, files may be accessed but not updated. Users evaluating procedures that perform updates enter a bumpable, swappable wait state (WT=20) and are suspended until the quiesce period ends.
Establishing an Extended Quiesce Before third-party backup utilities can be run, all files must be in an extended quiesce for updates. This means that although subsystems may be running and files may be opened for update, no in-flight-update transactions may be active. This Online state is achieved, in part, by using the following V5R1 command:
CHECKPOINT SET EXTENDED QUIESCE orCHECKPOINT SET E Q
This command only prepares the Online to enter the extended quiesce state. The Online actually enters that state upon completion of the next checkpoint. When this occurs, the following message is written to CCAAUDIT and to the operator’s console every 60 seconds:
M204.2610: SYSTEM ENTERED EXTENDED QUIESCE AT: 04.028 10:13:50, ALL FILE UPDATING REMAINS SUSPENDED
It is also displayed when the CHKMSG, CHECKPOINT MESSAGE, or MONITOR CHKP commands are issued.
Submitting Backup Jobs When extended quiesce is achieved, file backups using third party utilities can commence, because
When extended quiesce is entered, an internal event control block (ECB), CPQZ, is automatically posted. Posting the CPQZ ECB can then trigger evaluation to resume a User Language program that was previously waiting on the ECB with the $WAIT function. (While any number of UL programs may wait on a single ECB, for simplicity this article illustrates the process using only one program.) That program could:
The User Language program, after initiating any of the above actions, may then wait on the completion of those actions by issuing a $WAIT for another ECB, QZSIG, to be posted.
Ending Extended Quiesce
When the last backup job is complete, it can notify the Online, typically through a BATCH2 job step, by posting the QZSIG ECB. Alternatively, the system manager or DBA can manually run a User Language program that posts the QZSIG ECB, after ensuring that all backups are complete. Posting the QZSIG ECB then triggers evaluation to resume in the User Language program that is waiting on QZSIG. The program would then typically end the extended quiesce with the following command:
CHECKPOINT END EXTENDED QUIESCE orCHECKPOINT END E Q
The CHECKPOINT END E Q command may also be issued manually, but an efficient, automated facility for submitting backups would most likely issue the command. The command releases the lock that suspended all update procedures and allows normal Online processing to resume. When the extended quiesce ends, the following message is written to the operator’s console and CCAAUDIT. It is also available for display with the CHKMSG, CHECKPOINT MESSAGE or MONITOR CHKP commands:
M204.2613: SYSTEM ENTERED EXTENDED QUIESCE AT: 04.028 10:13:50, SYSTEM EXITED EXTENDED QUIESCE AT: 04.028 11:22:27, REASON = END COMMAND ISSUED BY USER NUMBER: 25
Other programs waiting on the QZSIG ECB will also resume evaluation and can now
Recapping the process The following steps, subject to modification depending on individual site requirements, are typical of what might transpire before, during, and after an extended quiesce:
1. Include the User Language program that waits on the CPQZ ECB, which is unposted when the system is not in extended quiesce. When extended quiesce is entered, this program can automatically submit third-party backup jobs and perhaps perform other extended quiesce processing. 2. Notify users that Online updates will soon be suspended. 3. Prepare the Online for extended quiesce by issuing the command SET CHECKPOINT E Q 4. Issue the CHECKPOINT command or wait for the next CPTIME checkpoint. 5. Issue a MONITOR CHKP command to verify that an extended quiesce began. 6. Ensure that backup jobs and other extended quiesce processing are happening. 7. Manually initiate any other processing required. 8. Monitor extended quiesce processing. 9. Ensure that extended quiesce ended when all backups and other processing completed.
Summary This article outlines how NonStop/204, a new and powerful V5R1 feature works. In the next issue of CCAPRINT, I will provide details and examples of how you can exploit this facility to implement third-party backups during production Online processing.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
