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.
APSY -- Precompilation Support Extended to Procedures with Commands By James Damon
One of the major benefits of defining Application Subsystems (APSY) and writing applications for those subsystems is precompilation, the process of compiling a User Language request and saving the compilation for future evaluation. Saving the compilation occurs only under APSY.
A User Language request must be compiled prior to evaluation. Compilation involves checking the syntax of each statement, field-name lookups in Table A for all fields referenced by the request, the creation of entries in NTBL, QTBL, STBL, VTBL, and the full screen buffer—if screens or images are defined. While compilation of a single request is relatively inexpensive, recompiling the same request thousands of times is resource intensive and can have a dramatic effect on user response times and Online performance.
Prior to Model 204 V6R1.0, APSY procedures containing commands preceding the BEGIN command or following the END statement were not precompilable. If such a procedure is invoked many times by hundreds of users, the overhead costs of recompiling the request can be substantial. In V6R1.0, precompilaton of requests is supported for requests containing commands that precede the BEGIN command or follow the END statement.
Typical Commands in APSY Procedures The most common commands issued from within an APSY procedure are the RESET and UTABLE commands. This is because the programmer has determined:
1. That certain parameters require guaranteed values. 2. Which server/compiler table sizes are required for successful navigation through the subsystem or, at least, through a portion of the subsystem.
The following could be a typical APSY procedure:
PROC LOGIN.PROCRESET HDRCTL=1UTABLE LSTBL=50000,LVTBL=1000,LGTBL=5000,LFSCB=8000BEGIN...%X = $SETG(‘NEXT’,’NEXT.PROC’)ENDEND PROC
In V6R1.0, this procedure is compiled and the compilation is saved.
Saving Compilations To compile a User Language procedure, the source code is read from the procedure file into the Model 204 buffer pool. A procedure with many lines of source code could span multiple Table D pages in the procedure file and each of those pages must be read into free buffers in the buffer pool.
Figure 1. A Model 204 Online address space
RESET HDRCTL 1 UTABLE …
CCATEMP 24
VTBL STBL
CCATEMP 33
NTBL QTBL
CCATEMP 32
RESET HDRCTL 0 USE PROC -2 R
CCATEMP 8
In Figure 1, let’s assume a procedure occupies two Table D pages (pages 8 and 9) in the procedure file. Therefore, two buffers (blue in Figure 1) in the buffer pool are used to receive those pages as the procedure is read in from the file. If this is an APSY procedure with the precompile prefix, only the first user invoking the procedure incurs the costs of compilation.
Under V6R1.0, the commands prior to BEGIN are copied and saved on as many CCATEMP pages as required. In Figure 1, CCATEMP page 24 (pink) is used. The User Language source code is then compiled and the results of compilation are entries in NTBL, QTBL, STBL, and VTBL, and those tables are also saved on as many CCATEMP pages as required; in Figure 1 CCATEMP pages 32 and 33 (green) are used. Finally, the commands following END are copied and saved; in Figure 1 on CCATEMP page 8 (pink).
CCATEMP pages 32 and 33 (green) constitute the saved compilation for the request. CCATEMP pages 8 and 24 (pink) constitute the saved commands. Future invocations of the procedure now execute the commands prior to BEGIN from CCATEMP page 24. Then the compiler tables are loaded from CCATEMP pages 32 and 33 into the running user’s server and the procedure is evaluated. At the end of evaluation, the commands following END are executed from CCATEMP page 8.
Monitoring CCATEMP pages used The total number of pages used for saved compilations, including saved commands, is reported in the output from the following MONITOR command:
MONITOR SUBSYS (PROCCT) subsysname
In Figure 2, seven procedures have been compiled and saved on twenty four CCATEMP pages.
Figure 2. MONITOR SUBSYS output
05.215 AUG 03 15.12.54 PAGE 198MONITOR SUBSYS (PROCCT) JIM1SUBSYSTEM NAME: JIM1SUBSYSTEM STATUS: ACTIVENUMBER OF USERS: 0NUMBER OF PRECOMPILABLE PROCEDURES (SAVED): 7NUMBER OF PRECOMPILABLE PROCEDURES (NOT SAVED): 29NUMBER OF NON-PRECOMPILABLE PROCEDURES: 7CCATEMP PAGES USED FOR PRECOMPILED PROCEDURES: 24NUMBER OF REQUESTS MADE RESIDENT: 0NUMBER OF ELIGIBLE REQUESTS NOT RESIDENT: 0STORAGE USED FOR RESIDENT REQUESTS: 0NUMBER OF RESIDENT PROCEDURE EVALS: 0NUMBER OF SWITCHES FROM RESIDENT MODE: 0
If you currently have many APSY procedures with commands prior to BEGIN or following END, you may notice an increase in CCATEMP page usage for your subsystems. Such procedures now consume CCATEMP pages both for compiling the User Language procedure and for storing commands. This cost should easily be offset by the elimination of repeated compilations of these procedures.
Although most compilations are saved under V6R1.0, you will continue to see the following messages for procedures that contain multiple BEGIN/END blocks or procedures that contain the MORE command.
M204.0468: COMPILATION NOT SAVED - MULTIPLE BEGIN/END BLOCKS NOT ALLOWED M204.0468: COMPILATION NOT SAVED - MORE NOT ALLOWED
Summary of Benefits The extension of precompilation support to APSY procedures containing commands is a performance enhancement that occurs automatically when V6R1.0 is installed. No parameter changes or changes to subsystem definitions are required. However, procedures with the non-precompile prefix will continue to be recompiled on each invocation. If you want those procedures to be precompilable, you must change the procedure-name prefix to the precompile prefix and you must change the next global variable that causes the procedure to be invoked. In many cases, the performance benefits may be quite noticeable with reduced user response times and increased transaction throughput.
System 1032 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.
Protecting VMS Files from the PC By Tym Stegner
This issue of CCAPRINT explores the transmitting of files to and/or from Customer Support via FTP and/or an e-mail service and recommends the preferred methodology.
“Hello, System 1032 Customer Support…” In the course of Customer Support operations, it often occurs that that you must supply files to Customer Support or we must supply you with software. Often we might need to transfer multiple text files or datasets. I suggest that you use the:
Sending and Receiving Gibberish However, often what happens is that when I receive the files from an e-mail message or via the CCA FTP server (FOX.CCA-INT.COM), I am completely unable to read the transferred files. This can also happen when I send files to you, the customer.
The problem turns out to be the middleman. The necessary files were transferred to a PC first, before being sent by an e-mail service or via FTP.
“Strange, It Looks OK on the PC…” There is a fundamental difference in the file structures between the VMS environment and the PC world. In the VMS environment, we have the concept of record-oriented structures (as well as all other file types, of course). In the PC world, the majority of the file structures are the C-oriented stream files that are without record structures.
Herein lies the bulk of our file transfer problems. If the necessary text files from the VMS system are first transferred to the PC, all the necessary metadata from the VMS file is lost, as the PC does not recognize, understand, or retain it.
Binary files are OK, as they are a fixed file structure, understood on the PC. However, while backup files are in a binary format, the PC transfer destroys the record marks necessary to successfully unpack the backup saveset.
Transmitting Text Files Successfully The ZIP utility is the best method to package and transfer text files. Not only does ZIP insulate the text files from losing their metadata to the PC file system, is also makes the files smaller. ZIP files can be transferred via FTP directly to another VMS system. You can also transfer ZIP files to a PC, and then transfer them via FTP or an e-mail message to CCA. As the ZIP files are fixed-format binary, their temporary stay on the PC files system does not alter them.
System 1032 ships with a copy of the ZIP utility and it is available in the S1032_IMAGE directory. The ZIP utility must be executed using a foreign command, so create one as follows:
$ ZIP :== $S1032_IMAGE:ZIP
The ZIP utility accepts two parameters: first, the zip file to be created or populated; second, the file or list of files to be compressed. To review the syntax and see available command options, execute ZIP without any parameters to display the help page.
ZIP Utility Limitations Unfortunately, due to the manner in which datasets are structured (block #2 is 13,000 bytes long), you cannot use the ZIP utility on a dataset.
Transmitting Dataset Files Successfully To transfer a System 1032 dataset, we use the VMS BACKUP utility to contain the dataset before transmitting it via FTP. As previously described, however, transmitting the backup saveset to the PC first muddles the record sizes and the resulting backup saveset cannot be restored on the destination VMS system.
Fortunately you can restore the necessary file attributes to the backup saveset, because the necessary record length is encoded within the backup saveset file. You can extract encoded record length from the saveset file and use the data to restore the file.
For most saveset files, the record length is set to 32,256 bytes by the BACKUP program. Fixing this value on the saveset file lets the BACKUP command restore its contents to disk. You can use the commands in Figure A to restore a saveset muddled by an FTP transfer:
Figure A. Restoring a saveset
$ open/read save_set whatever.BKP$ read save_set first_block$ rec_size = f$cvsi(0,16,f$extract(40,2,first_block))$ close save_set$ set file 'save_set'/attr=(rfm:fix,lrl:'rec_size')$ write sys$output "Record size changed to: ",rec_size
The first record of the saveset contains the necessary data that can be used to restore the saveset. The Figure A code reads out this value and converts it to Integer from Binary. That data is used in a SET FILE command to change the file attributes of the saveset file back to FIXED format, and sets the proper record length.
We can supply you with a UNFTP.COM command procedure that automatically handles this operation. Send your request via e-mail to 1032_support@cca-int.com for a copy.
In Summary You can easily transfer files to or from Customer Support, as long as you realize that an intermediate, albeit necessary, transfer to a PC will alter the necessary VMS file attributes. Use the techniques described in this article to transfer files, so you (and I!) will not have any problems reading the files.
