Providing Input to Applications: Part 1 By Tym Stegner As new System 1032 programmers are hired and established System 1032 programmers have their responsibilities expanded, they are confronted with applications that may require modernizing to accept newly required data or other adjustments. This article and those that follow provide you with a look at how applications are designed to accept input from users, so that you can properly maintain them and edit them.
This multi-part installment explores the question of providing input to applications. Various solutions are explored. The series was prompted by a programmer, new to System 1032, who sent in the following question.
Reviewing How Input Is Obtained by System 1032 We will consider four distinct mechanisms for prompting or parameter passing for COM-to-DMC operations. I will present these mechanisms from the most simple to most complex. The four mechanisms break out as follows:
Option #1. Doing All the Work within System 1032 This is the introductory method of parameter passing for a beginning System 1032 programmer, as it concentrates on the System 1032 command set and removes the need to coordinate between OpenVMS and System 1032.
Doubtless you have already been exposed to the idea of defining commands at the OpenVMS level. You use the same sort of coding to create an OpenVMS command to run a System 1032 DMC file. This also makes use of the built-in capability to specify commands on the System 1032 command line. The following example DMC file is named TTT.DMC. (Reminder: OpenVMS and System 1032 comments are denoted by an exclamation mark (!).
! TTT.DMCVariable ASK Text VaryingAccept ASK Prompt "Enter text: "Print ASK
We can run the DMC file directly via System 1032 from the DCL command line, as follows. This time we will issue a SET VERIFY command to see what is being done. Also, note the use of the semi-colon as a command separator.
$ S1032 Set Verify; Use TTT; ExitVar ASK Text VaryingAccept ASK Prompt "Enter text: "Enter Text: wibblePrint ASK ASK--------------------wibble
Next, I will define a DCL command symbol to run this automatically:
$ Doask :== 'S1032 Use TTT; Exit A command definition does not automatically translate other command symbols, of which S1032 is one. Therefore, I used an accent mark to force a translation of the command symbol in our new command.
$ DoaskEnter Text: wibble ASK--------------------wibble$
Option #2. Enclosing Our DMC File within a COM File I will go up one level of complexity by using a COM file to launch a DMC file, by enclosing the DMC file we just used within a COM file.
$! ASK.COM - Drive a System 1032 DMC file$!$ S1032USE TTTEXIT$!$ Exit $ @AskComputer Corporation of America System 1032 Version V9.81-1Copyright 2002, Computer Corporation of America ASK--------------------EXIT%S1032-E-EXITING, no more commands to process – exiting$
The COM file successfully launched the DMC file. However, the previous example illustrates an important point. Did you notice that I was never prompted to enter any text? In fact, I got an error about no commands to be processed! The command flow within a COM file is reason for this error.
DCL command files operate like card decks from Early Computing Time: one card at a time, no going back, no loops. In a card deck, there is no way to prompt for information, so all commands and data must be present within the card deck. Therefore, in the standard COM file, everything needed by the System 1032 DMC must already be in the COM file.
Supplying Input within the COM File
Some applications expect the same input every time they are invoked. To make TTT work for such a single-minded application we can add the text to be entered to the COM file, as follows:
$! ASK.COM - drive a System 1032 DMC file$!$ s1032USE TTTwibble !note new lineEXIT$!$ Exit $ @AskComputer Corporation of America System 1032 Version V9.81-1Copyright 2002, Computer Corporation of America ASK--------------------wibble$
DCL reads the next line from the command file when the underlying program asks for input. For some applications, this COM could be enough, especially where the prompted data changes only rarely. Should a value change be required, the COM file itself is modified.
However, this is not the method to use when we want our application to prompt for data.
Obtaining Data from within a COM File
To get input from the OpenVMS command line, we need to redefine the command stream’s input channel before System 1032 is started, so that the COM file will read from the terminal, instead of from the COM file:
$! ASK.COM - Drive an S1032 DMC file$!$ Define/User_Mode Sys$Input Sys$Command$ S1032; USE TTT; EXIT$!$ Exit $ @AskEnter Text: wobble ASK--------------------wobble$
The OpenVMS DEFINE command is used to declare logical names. The /User_Mode switch directs OpenVMS to automatically deassign the logical name after the next image is run, in this case, System 1032 itself. Otherwise, the logical name should be manually deassigned after the System 1032 portion of the DCL command file, so as not to leave the default input channel redirected.
SYS$INPUT and SYS$COMMAND are process-defined I/O channels that are always available within your process or within a COM file. Their definitions will change slightly depending upon whether you are processing interactively or from within a command file. (Try the DCL Show Symbol command to see what their definitions may be.)
The coding sequence here is that we must tell the COM file to take input from the terminal, not from the command file, just before we start System 1032. This is what the OpenVMS Define/User_Mode command is doing.
Note that the commands are back on the command line, as is required by the input redefinition. Since commands will not be read from the COM file, they must all be placed on the command line.
Summary In this installment, we looked at two of the available mechanisms that allow prompting for input data for System 1032 command files or applications. The techniques are useful to all System 1032 programmers, if only to understand how their existing applications work. In our next installment, in response to the customer question, we will move the onus of prompting out of System 1032 and into the DCL command file itself.
Model 204 USE OF AND ACCESS TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.
Backing Up Model 204 Files with DUMP during Update By James Damon
Every organization needs current backups of data files. Backups must often be scheduled at night or on weekends when the data is in a quiescent state--that is, when no updates are being performed. If backups were to occur while a data file was being updated, the integrity of the backup would be in doubt. If an update transaction was in flight and not yet committed, the backup would only contain part of the update. However, with systems approaching 24/7 availability, a quiescent state is often difficult or even impossible to attain.
So, a system manager or DBA would ask, "Is there a facility that circumvents this limitation and still guarantees the integrity of my backups?" With Model 204, the answer is, "Yes! DUMP during update." This facility creates a copy of the file as it looks at the time the DUMP command is issued. Any updates that occur after the DUMP starts will not be reflected in the DUMP copy.
Using the DUMP Command You can back up a Model 204 file using the DUMP command. The syntax of the command is simple.
DUMP TO ddname
The DUMP command operates on the current default file and, therefore, accepts as an argument only the ddname of the target dump dataset.
All pages currently in use in the file are read into the buffer pool and written to the dump dataset, usually in sequential order: File Control Table (FCT) pages in use (the File Parameter List (FPL) only), followed by Tables A, B, C, D and E. All pages in Table A and C are considered in use and are always dumped.
However, empty pages are not dumped. If BSIZE=50000 and BHIGHPG=2500, then only 2500 Table B pages are written to the dump dataset. The same applies to Table D and DSIZE, DPGSUSED and to Table E and ESIZE, EPGSUSED.
Processing DUMP During No-Updates Figure 1 shows how pages are read into the buffer pool and written to the dump dataset by DUMP command processing. In this example, no updates against file MYFILE are in progress when USER25 issues the DUMP command.
Figure 1. Model 204 Online with DUMP command active
Processing DUMP During Update Now consider the same Online with additional users logged in and performing updates against MYFILE1. Figure 2 shows the same schematic as in Figure 1 with a few differences.
Figure 2. Model 204 Online with DUMP command active and updates in progress
When USER25 issues the DUMP command, assuming all updating users are at a COMMIT point, DUMP processing begins and pages are read from file MYFILE1 into the buffer pool and written, in the sequence mentioned previously, to dump dataset DUMPMYF1. However, if another user attempts to update a record on Table B page 257, that update will be delayed momentarily while page 257 is dumped, out of sequence, to the dump dataset. When that I/O completes, the update proceeds and DUMP processing resumes with the next page in normal file sequence.
The update to the record on Table B page 257 will not be reflected in the backup copy. Similarly, if that update also involves an update to ordered index page D15, that page will be dumped out of sequence to the dump dataset before the update is allowed to proceed. Again, that update will not be reflected in the backup copy.
Processing DUMP with Updates in Flight If all updates are not at a point of commit when USER25 issues the DUMP command, the following messages are issued:
DUMP TO DUMPHILO*** M204.1760: FILE K100HILO: DUMP BEGINNING AT 08.282 OCT 08 12.43.35*** 3 M204.0602: FILE IS IN USE*** M204.1076: DO YOU REALLY WANT TO TRY AGAIN?
USER25 can respond ‘Y’ to message M204.1076 and Model 204 will try to restart DUMP processing. When all users are at a point of COMMIT, DUMP processing resumes and runs to completion, possibly dumping pages out of sequence to allow for updates. The backup copy is a copy of the file as it was at the instant DUMP processing began. Updates applied to the file after the dump began will not be present in the backup copy.
DUMP Processing Using Non-Model 204 Utilities If you prefer to dump many files concurrently using non-Model 204 utilities such as FDR, DFDSS, SnapShot Copy and others, you should consider using the Extended Quiesce feature in Model 204. I discussed this at length in previous issues of CCAPrint:
February 2004: V5R1 - NonStop/204; Extending 24*7 Capabilities - Part 1 March 2004: V5R1 - NonStop/204; Extending 24*7 Capabilities - Part 2
In Summary If you need to backup Model 204 files during the normal hours of production operations, then the DUMP during update feature is the solution.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
