download RFT/DCA converter for Word copy Rftdca32.CNV from zip file to
C:\Program Files\Common Files\Microsoft Shared\TextConv
run the Regfile, and then you can open .RFT files in word 2003 ok
file from word (no spelling mistakes) just appears to have random '*' here and there!
[FONT="]OTIS Development - Programming Standards[/FONT][FONT="]
Version 1.0[/FONT]
[FONT="]1. Introduction[/FONT]
[FONT="]These project standards must be followed when coding COBOL II/ CICS/ DB2 programs in the OTIS environment.[/FONT]
[FONT="]The existing 'skeleton' program should be used as the basis for new modules wherever possible.[/FONT]
[FONT="]2. Comments[/FONT]
[FONT="]Comments should be used to improve the clarity of pro*grams by de*scribing any details that are not obvious from the code. Avoid using COBOL reserved words and ensure that com*ments are clearly identified by using more than one as*terisk at the start of the line. Programs will not generally be pro*moted from the TEST envi*ronment if they con*tain 'com*mented out' code.[/FONT]
[FONT="]The 'program header' comments block must contain the following:[/FONT]
[FONT="]OTIS system and subsystem.[/FONT]
[FONT="]Program name and CICS transaction name.[/FONT]
[FONT="]Map and mapset.[/FONT]
[FONT="]References to the logical/physical design specs. if appli*[/FONT]
[FONT="]cable.[/FONT]
[FONT="]Program description - narrative describing the function of [/FONT]
[FONT="]the program and the processing it performs. This should be [/FONT]
[FONT="]about 5 to 10 lines.[/FONT]
[FONT="]Statement of program I/O including TSQs, TDQs, and DB2 [/FONT]
[FONT="]tables used.[/FONT]
[FONT="]Navigation Details - other transactions invoked from this [/FONT]
[FONT="]program, where this program was invoked from.[/FONT]
[FONT="]Modules called - list of other programs (e.g. common modules) [/FONT]
[FONT="]called.[/FONT]
[FONT="]Change log containing: version number, ICR and/or Fault [/FONT]
[FONT="]number, date changed, by whom, and description of change.[/FONT]
[FONT="]Where appropriate, use in-line comments to show the start and end of new or modified code when amending existing programs, and en*sure that 'header block' comments (as well as the change log) are amended as necessary.[/FONT]
[FONT="]3. Data Division[/FONT]
[FONT="]Each functional group of working storage variables should be pre*ceded by a comment header block. Groups will be coded in the fol*lowing order:[/FONT]
[FONT="]Constants[/FONT]
[FONT="]Variables[/FONT]
[FONT="]Print Lines[/FONT]
[FONT="]SQL includes[/FONT]
[FONT="]OSKER includes[/FONT]
[FONT="]Abend Routine includes[/FONT]
[FONT="]Commarea includes[/FONT]
[FONT="]A unique literal string should be coded at the start of each func*tional section of working storage to assist in reading memory dumps.[/FONT]
[FONT="]Working storage variables will have a 2 charac*ter prefix, as fol*lows:[/FONT]
[FONT="]WC- Constant[/FONT]
[FONT="]WV- General variable[/FONT]
[FONT="]WS- Screen[/FONT]
[FONT="]WF- Flags[/FONT]
[FONT="]WI- Index[/FONT]
[FONT="]WA- Accumulator/counter[/FONT]
[FONT="]WP- Print line[/FONT]
[FONT="]WD- Date[/FONT]
[FONT="]WL- Linkage copy area[/FONT]
[FONT="]Working storage variables should be coded such that functional groupings of variable names begin with an 01 level identifier and lower level identifiers are at levels 03, 05, 07, etc. Variables with the same level should be coded in the same column, with each suc*cessive level indented by 4 columns.[/FONT]
[FONT="]88 levels may be used in conjunction with the COBOL II SET state*ment to enhance readability.[/FONT]
[FONT="]Where possible, use COMP-3 for numeric variables as it is easier to identify and read in working storage than COMP.[/FONT]
[FONT="]4. Procedure Division.[/FONT]
[FONT="]The Procedure Division will be coded using COBOL sections. Each section will be terminated by a paragraph containing an EXIT statement.[/FONT]
[FONT="]Section names should be placed in a comment box. A brief narrative description of the processing should be in*cluded if necessary but avoid stating the obvious.[/FONT]
[FONT="]Section names will take the form 'xnnnn-name' e.g. C3000-BUILD-SCREEN. Section names start*ing with A-D will be used for sections that form the main struc*ture of the program, and X-Z will be used for any 'common' sections that are called in more than one place (e.g. abend han*dling). The 'nnnn' component indi*cates the level and execution sequence of each section, so C3000-might perform C3100-, C3200- and C3300-. The section-name part will be a mean*ingful name within the context of program process*ing.[/FONT]
[FONT="]The structure and section names used in the 'skeleton' program should be followed wherever possible.[/FONT]
[FONT="]Sections should be coded in alphanumeric order within the Proce*dure Division.[/FONT]
[FONT="]A page break will be coded at the start of each section and, where possible, the section should not exceed one printed page in length.[/FONT]
[FONT="]Indent COBOL statements and use COBOL II scope delimiters to im*prove readability. As a guide, a typical IF-THEN-ELSE statement would be coded as follows:[/FONT]
[FONT="]IF condition-1[/FONT]
[FONT="]statement-1[/FONT]
[FONT="]IF condition-2[/FONT]
[FONT="]statement-2[/FONT]
[FONT="]ELSE[/FONT]
[FONT="]statement-3[/FONT]
[FONT="]END-IF[/FONT]
[FONT="]ELSE[/FONT]
[FONT="]statement-4[/FONT]
[FONT="]END-IF.[/FONT]
[FONT="]Avoid excessively complicated nested IF statements. Use the COBOL II EVALUATE verb to handle case structures.[/FONT]
[FONT="]COBOL GOTOs should not be used except where it is necessary to transfer control to a section exit.[/FONT]
[FONT="]5. Abend Handler[/FONT]
[FONT="]At the start of the program, move the following values to the ap*propriate 'WZ-ABEND-' variables used by the abend handler:[/FONT]
[FONT="]Program name[/FONT]
[FONT="]Previous program name (if applicable)[/FONT]
[FONT="]OTIS nickname of user[/FONT]
[FONT="]Parameters passed to the program[/FONT]
[FONT="]Use WZ-ABEND-TEXT01 to TEXT04 for descriptive text as appropriate within the pro*gram flow.[/FONT]
[FONT="]After each SQL call, move the follow*ing values to the ap*propriate 'WZ-ABEND-' variables, then perform a common routine to check the re*sult of the call:[/FONT]
[FONT="]DB2 table name[/FONT]
[FONT="]Key values[/FONT]
[FONT="]DB2 action (SELECT, UPDATE, etc.)[/FONT]
[FONT="]6. General Guidelines[/FONT]
[FONT="]The COMMAREA should be moved to an area of Working Storage as part of initial program processing and moved back to the Linkage Sec*tion immediately before a call to OSKER or a return to CICS. Use the copy library definitions set up for this purpose.[/FONT]
[FONT="]Do not code CICS HANDLE CONDITIONs. Use the RESP(WV-RESP) option in CICS calls, and then test WV-RESP for DFHRESP(condi*tion) to evaluate execution results.[/FONT]
[FONT="]Ensure that the follow*ing are catered for and processed correctly:[/FONT]
[FONT="]- SQL deadlocks / timeouts in DB2 accesses[/FONT]
[FONT="]- DB2 RI considerations before add/delete[/FONT]
[FONT="]- DB2 Null indicators[/FONT]
[FONT="]- 'Logically deleted' records (ACTIVE-IND = 'N')[/FONT]
[FONT="]- OSKER application access levels[/FONT]
[FONT="]The physical positions of screen fields should be coded in working storage, where they can easily be identified and amended should the layout change.[/FONT]
[FONT="]Dynamic calls to other programs should be coded in a standard way to allow the gen*eration of cross-reference listings from the COBOL source.[/FONT]
[FONT="]Example: CALL WC-DEXP207 USING ....[/FONT]
[FONT="](where WC-DEXP207 contains "DEXP207").[/FONT]
[FONT="]Take care with opening and closing of cursors. Only open them when needed and close again as soon as possible.[/FONT]
[FONT="]To avoid implicit GOTO's, do not use the SQL WHENEVER NOT FOUND construct.[/FONT]
[FONT="]In general, DB2 variables should be read into host variables con*tained in the included DCLGEN member for the table.[/FONT]
[FONT="]7. Other related documents[/FONT]
[FONT="]The following ITS/2 publications contain specific guidelines on DB2 usage which should be followed wherever possible:[/FONT]
[FONT="]"Data Management Guide" - Terry Dunwoody, ITS/42, 17/5/90. [/FONT]
[FONT="]The most relevant part (Section 6, "SQL Guidelines") is cur*[/FONT]
[FONT="]rently being revised and will shortly be re-issued).[/FONT]
[FONT="]Data Management Series No. 11, "Order of Data Access in Ap*[/FONT]
[FONT="]plication Programs" - P. Hall, ITS/42, 21/1/91.[/FONT]
[FONT="]Data Management Series No. 12, "Deadlock and Resource Un*[/FONT]
[FONT="]available SQL Codes" - P. Hall, ITS/42, 21/1/92.[/FONT]
[FONT="]The checklists associated with the OTIS Program QA Procedure con*tain de*finitive de*tails of project standards for screen layout (colour, spacing, de*scriptive text etc.), and "standard" PF key processing / message texts.[/FONT]
that I'm trying to open.
