FAQ for the REVIEW TSO Command

Q: What is "REVIEW"?
A: REVIEW is a TSO command processor, which is another way of saying it is a program which expects to be passed a TSO command processor parameter list (CPPL).

Q: What is the function of REVIEW?
A: To format and present file data for inspection, edit, update and extraction using fullscreen mode of 3270-family TSO terminals.

Q: What sort of files can REVIEW process?
A: Tape data sets and disk (DASD) data sets. VSAM data sets and non-VSAM data sets. Permanent data sets and temporary data sets. Sequential (TAPE and DASD), partitioned (PDS and PDSE), indexed sequential, direct access, subsystem, VSAM (KSDS, ESDS, RRDS with fixed- or variable-length records, LDS, AIX, PATH, VVDS, BCS, DATA and INDEX components) data sets, DB2 tablespaces, VTOCs and VTOC indices, and files accessible to UNIX System Services such as HFS (Hierarchical File System) files.

Q: How is the file to be processed specified to REVIEW?
A: By data set name, file (DD) name, or path name.

Q: How does REVIEW know the type of the specified name?
A: The first operand of the REVIEW command is the specified name. If it begins with a slash ('/') then it is deemed to be a path name. If the FILE operand is specified then it is deemed to be a DDname. Otherwise it is deemed to be a data set name. Standard TSO rules regarding the processing of unquoted data set names for high-level (prefix) and low-level qualifiers apply. The QUICK operand will prevent the addition of any low-level qualifier.

Q: What record formats can REVIEW process?
A: F,FB,FS,FBS,V,VB,VS,VBS,U with or without carriage control (A or M). For spanned variable-length records, LRECL=X support is limited to records up to 65535 bytes long.

Q: What if no DCB (RECFM/LRECL/BLKSIZE) values are present in the data set labels?
A: REVIEW will use RECFM=U,BLKSIZE=32760.

Q: Is REVIEW an ISPF application? (Updated for R37)
A: It can be. Like ISPF, RMFMON and SDSF (when invoked from the READY prompt) REVIEW is a fullscreen TSO application. Unlike the SDSF command, for example, REVIEW can handle screens with more than 4096 display locations. REVIEW also exploits extended 3270 features such as colour, extended highlighting, APL character set, and character (raster) and vector graphics. REVIEW also exploits 3270 data compression to reduce data stream lengths. When REVIEW is invoked in an ISPF environment it can operate an an ISPF application.

Q: Can data sets be edited with REVIEW? (New for R38)
A: Yes, REVIEW includes a fullscreen editor known as REVEDIT.

Q: What data sets can be edited by REVEDIT? (New for R38)
A: Currently only sequential and partitioned data sets (except those with an undefined record format or spanned records) can be processed by REVEDIT.

Q: How is REVEDIT invoked? (New for R38 - Updated for R41)
A: REVEDIT can be invoked when a PDS or PDSE member is selected with the 'U' selection code, and by the UPDATE primary command.  The 'E' member selection code and the EDIT primary command will also invoke REVEDIT when REVIEW is not running in an ISPF environment. Further, when the REVED (as opposed to REVIEW or REV) TSO command is used, a sequential data set will edited directly, and 'U' becomes the default selection code for partitioned data set members.

Q: How big a data set can be processed by REVEDIT? (New for R38)
A: REVEDIT reads the data set to be edited into virtual storage. As the data grows during the intial read and during the edit process more virtual storage is dynamically acquired.  There is a 16-byte overhead for each record, and for variable-length records the maximum length is allocated for each record. Thus the maximum edit data set size is limited by the user's REGION size (also taking into account other programs and data which must reside in the REGION) or by the site's limit of data space usage (usually implemented via IEFUSI) up to 2 gigabytes. An assemble-time "gen option" specifies whether REVEDIT is to use REGION storage or a data space to back data being edited. The amount of storage acquired to back the data being edited can be shown with the PROFILE or PROF subcommand of REVEDIT.

Q: Can REVIEW use ISPF EDIT and/or BROWSE and/or VIEW?
A: Yes, but only in an ISPF environment. This means that if REVIEW is invoked from the READY prompt then ISPF services are not available.

Q: What sort of things can be edited or browsed with ISPF from REVIEW?
A: Directory entries can be selected with an 'E' or 'B' or 'V', as appropriate. This applies to both PDS and PDSE directories, and UNIX directories. The selected entries must be acceptable to the ISPF service. MVS data sets or PDS(E) members being REVIEWed can be processed by the EDIT or BROWSE or VIEW subcommands of REVIEW.

Q: What has to be done to get REVIEW to operate as an ISPF application? (New for R36)
A: Install the REVPANEL member into an ISPPLIB library and the REVPROF member into the ISPPROF data set.

Q: And then will REVIEW always run as an ISPF application? (Updated for R37)
A: Unless XISPMODE (or X for short) is specified, yes.

Q: How are parallel REVIEW sessions created? (New for R36)
A: While REVIEWing data natively (that is, when not running as an ISPF application) and "TSO REV" is issued to REVIEW another file, REVIEW is invoked recursively and the current session is nested below the new session which is created by this command. Issuing "SWAP LIST" at any time shows all REVIEW sessions which can be the target of a "SWAP" command. Swapping between all types of REVIEW sessions (OS data set, PDSE, UNIX file, fullscreen help, VSAM data set) is permitted.

Q: What screen sizes does REVIEW support? (Updated for R37)
A: Any screen size with at least 24 lines and 80 columns, and with an even number of columns.

Q: Why does REVIEW trap TSO attention interrupts? (Added Oct 2004)
A: When REVIEW detects an attention interrupt operations such as scrolling, searching, directory reading, directory sorting, and file offloading are terminated so that the user can have an opportunity to enter a new request more quickly. Because REVIEW does not terminate the whole session the user can often use this facility to gauge progress, and resume the operation if appropriate. Sometimes the user can initiate a new more efficient request. Suppose a request such as f varying is issued for a very large file. The user might realise that this will take "too long". By interrupting the search, and issued the new request f c'VARYING' the user will trigger a much more efficient search - one which searches for upper case text only.

Q: Apart for presenting the raw data, what special formatting can REVIEW perform?
A: REVIEW has built-in support for formatting some SMF, LOGREC (EREP) and VTOC data. REVIEW will show the RID (row-id) of DB2 table rows. REVIEW can process Assembler DC and DS statements to format records by data item. REVIEW will interpret CESD and IDR records in load modules. REVIEW will interpret and format tape labels. REVIEW will attempt to render Paintbrush (PCX) files on 3270 graphics terminals. REVIEW can format ZIP file directories. When invoked as "fullscreen help" REVIEW interprets TSO HELP control statements. The ASCII command allows the display of ASCII data.

Q: What is the fullscreen help function?
A: REVIEW provides a comparable function to the HELP command of TSO, the main difference being that the HELP text is presented in a fullscreen fashion rather than in line mode. This allows scrolling up to a page just passed, and the issuing of FIND commands.

Q: How is the fullscreen help function invoked?
A: Once REVIEW is installed, just issue FSHELP (or FSH or HEL) instead of HELP. FSHELP supports all the same operands as TSO's HELP. If FSHELP cannot handle an operand correctly, it simply transfers control to HELP. The XCTL subcommand of FSHELP allows this transfer to be triggered manually.

Q: If FSHELP has the same entry point as REVIEW, how does REVIEW know which function is requested?
A: REVIEW looks at the name which it was invoked with. If it is not one of the known HELP function names then REVIEW performs standard processing. This is why FSHELP cannot be installed under any name without source code changes. (Exercise for the reader: REVIEW the data set 'SYS1.CMDLIB', press PF10 to sort into TTR order, and type 'L IDCAM01' (without the quotes) in the locate field, and look at the entry points of all the aliases. Also look at IDCAM02 and IDCAM03.)

Q: How is the REVIEW of a VTOC requested?
A: A data set name of 'FORMAT4.DSCB' (including the quotes) is specified, as is the VOLUME operand to nominate the specific VTOC to be processed.

Q: How can VTOC entries be formatted?
A: While REVIEWing a VTOC, issue the 'FMT ON' subcommand to format each line into format-1 DSCB fields. 'FMT OFF' can be used to deactivate the VTOC formatting. Use 'F 1 45 ALL' to restrict the display to format-1 DSCBs only.

Q: Which code page does REVIEW use for ASCII translation?
A: REVIEW uses the XLATE macro which invokes SVC 103. This is the same translation that is done when OPTCD=Q is specified for ANSI tapes. Module IGC0010C contains both of the relevant translate tables. A usermod could be applied to this module if changes to the tranlate tables are required.

Q: How good is REVIEW's multi-volume support?
A: Not very. While scrolling down is no problem, scrolling up to a previous TAPE or DASD volume does not work. Scrolling up to a previous data set in a concatenation of sequential data sets does not work. When a concatenation of libraries is opened (using BPAM) the contents of all libraries are accessible. When a concatenation of sequential files is opened (using BSAM or QSAM) no more than one data set is open at any moment. The use of BDAM would allow concurrent access to all extents of a multi-volume DASD data set, but this would not assist multi-volume tape data set processing.

Q: Why is REVIEW link edited with AC=1?
A: So that it can run APF authorised. It will only run APF authorised if installed into an APF authorised library, and registered as an authorised command to TSO. REVIEW does not issue any MODESET macros, and does not switch to any system key or supervisor state.

Q: So should REVIEW be registered as an authorised TSO command?
A: No. The 'REVIEW' command, and its abbreviation 'REV' are intended to be the general invocation names for normal processing which should not require APF authorisation.

Q: What doesn't work when REVIEW runs APF authorised? (Updated for R36)
A: ISPF services cannot be invoked in an APF authorised environment. The TSOEXEC front-end used by the TSO subcommand to afford REVIEW some protection from TSO commands issued in a REVIEW session is not used in an APF authorised environment. When TSOEXEC is not used, REVIEW will attach the TSO command itself instead of linking to TSOEXEC.

Q: What is "REVVSAM"?
A: REVVSAM is an alias of REVIEW that is intended to be registered as an authorised TSO command. When REVIEW processing requires APF authorisation then the REVVSAM command should be used instead of REVIEW or REV.

Q: Why is it called "REVVSAM"?
A: Originally REVIEW could only process non-VSAM data sets. Then it was enhanced to use BSAM to read VSAM components which had their own VTOC entries. With DFP Version 3 it became a restriction that non-VSAM access to VSAM data sets was not allowed unless the environment was APF authorised. So, whenever a VSAM data set was to be REVIEWed, REVVSAM rather than REVIEW was issued.

Q: Is REVVSAM still needed to look at VSAM data?
A: No. VSAM I/O is now used to access all flavours of VSAM files, and this does not require APF authorisation.

Q: So what is REVVSAM good for?
A: When REVIEW runs APF authorised and the specified data set is a VSAM component (data or index) with its own VTOC entry REVIEW will access the component with a DCB (BSAM) instead of an ACB (VSAM), as long as the component does not have more than sixteen extents. This means that VSAM data can be accessed even when some control information used by VSAM has been corrupted ot lost. It also means that VVDS and BCS data can be browsed. APF authorisation also allows the processing of subsystem data sets.

Q: So it doesn't have to be called "REVVSAM"?
A: No, it could be renamed to "REVAUTH", for example. It would be advisable to keep the REVIEW TSO HELP member contents and aliases synchronised with any name change, as well as the text of messages in the REVIEW source code.

Q: What is in the REVIEW profile?
A: The REVIEW profile contains information that is remembered across REVIEW sessions. It contains the REVIEW release which last wrote it, the colours to use for formatted, character and hexadecimal data display, the scroll amount, the code point display mode, the time and date it was last written, and the commands assigned to the 24 program function keys.

Q: How big is the REVIEW profile and where is it kept?
A: The REVIEW profile is currently 1600 bytes and resides in member $$REVIEW in the library allocated to the ISPPROF data definition. Once written, subsequent updates are done in-place to avoid the consumption of disk space. It is only rewritten if changed.

Note: Users on systems without ISPF may still wish to arrange for the ISPPROF file to be allocated to a personal PDS so that customized settings such as PFK meanings, and editor settings such as HILITE and ZAP can be retained across REVIEW sessions.

Q: What about the function key settings used when REVIEW is an ISPF application? (New for R36)
A: These are kept in member REVPROF which must reside in the data set allocated to the ISPPROF file. The ISPF keylist used is called REVKEYL. This scheme ensures that REVIEW PFK settings do not interfere with the profile settings of other ISPF applications.

Q: How does REVOUT work? (Added Dec 2007)
A: REVOUT invokes the REVOUTJB CLIST which executes the TSO STATUS command and captures the output with the CLIST SYSOUTTRAP facility, and displays the results for user selection. When the user selects a job for viewing REVOUT invokes the TSO OUTPUT command and browses the resulting temporary data set.

Notes for MVS 3.8: The SYSOUTTRAP facility can be added to TSO by usermod ZP60014. Usermods ZP60015 and ZP60016 together can be used to enhance the power of STATUS without operands to search for up to three job name suffix characters.

Q: What types of pictures can be displayed by REVIEW? (Updated for R41)
A: 1-bit, 4-bit and 8-bit single-plane PCX (ZSoft Paintbrush) files, and 1-bit, 4-bit, 8-bit, 16-bit, 24-bit and 32-bit uncompressed single-plane BMP (Windows and OS/2 bitmap) files. The files are recognised by data content when the first record is at least 80 bytes long.

Q: So REVIEW can display 256 different colours on a TSO terminal?
A: No. If an R, G or B value is 128 or higher (255 is the maximum) then that colour (red, green or blue) is activated for that pixel. A value below 128 (ie. from 0 to 127) keeps that colour inactive for that pixel. The 3270 data streams employed only provide support for eight different colours (including black).

Q: Could support for other picture types be added?
A: Code to recognise and process other picture types (bitmap types would no doubt be easier to handle than vector types) could be added to convert the picture data to REVIEW's internal byte-per-pel array, which could then be displayed by existing code. Code donations are welcome.

Q: Can I export the pictures to other applications?
A: Yes. The PICDATA subcommand causes Assembler source DC statements containing the picture's bitmap data to be written to a sequential file for inclusion into an application's source code.

Q: How can I stop REVIEW rendering the picture to see the raw data?
A: Enter the 'FMT OFF' command. If the command line is not visible because of the picture display, press ENTER first. The picture will not be displayed again until the data is REVIEWed again.

Q: How can I stop REVIEW attempting to render the picture at all?
A: For a sequential file, REVIEW it with the DATA operand. For a PDS or PDSE member, or for a UNIX file, select the entry with a slash ('/') rather than with an 'S'.

Q: How can I get REVIEW to render a picture under ISPF? (New for R36)
A: Invoke REVIEW with the XISPMODE operand, even if REVIEW is not running as an ISPF application. With OS/390 2.10 (and later) REVIEW ascertains colour, highlighting and Graphic Escape support from ISPF variables to avoid the extra initialization overhead of querying the terminal. As a result REVIEW can show the inital data screen more quickly, but it cannot determine if the terminal has any graphics capabilities. The XISPMODE operand will not only suppress any ISPF dialog usage for REVIEW presentation, but will also cause REVIEW to issue a Query to the terminal itself if the Query bit is on.

Q: When will REVIEW recognise a ZIP file?
A: When the ZIP file is in its own DASD sequential data set (and when the VTOC entry is "in sync" with the data), or when the ZIP file is a UNIX file. ZIP files in PDS or PDSE members or on tape will not be recognised.

Q: Can REVIEW unZIP data? (Updated for R38)
A: Not directly, but if MINIUNZ is installed then REVIEW will call it to unzip the cursor selected file so that its data can be REVIEWed.

Q: How can I stop REVIEW attempting to interpret a ZIP directory?
A: For a sequential file, REVIEW it with the DATA operand. For a UNIX file, select the entry with a slash ('/') rather than with an 'S'.

Q: How can a tape data set be REVIEWed?
A: Place the tape in a tape drive, and wait for the drive to become ready. (Cartridge is the same as tape in this context.) Then issue the REVIEW command. This method exploits AVR (Automatic Volume Recognition). If the TSO user id has the TSO MOUNT privilege then the REVIEW command can be issued first and the system will issue a mount message to the system console.

Q: What if the data set is not the first on the tape?
A: If the data set is catalogued correctly then the file sequence number should not matter. If the data set is not to be allocated via the catalog entry then the data set can be pre-allocated using a TSO ALLOCATE command and the DD name can then be REVIEWed. The REVTAPE CLIST may be used to advantage in this situation.

Q: How can tape labels be REVIEWed?
A: The first (or other appropriate) file on the tape must be allocated using BLP. The Job Entry Subsystem must allow BLP for the TSU job class, and the system security product must allow access to BLP. The REVTAPE CLIST may be used to advantage in this situation.

Q: What PDS member userdata can REVIEW report?
A: As well as showing the list of members in a PDS, other directory information can also be shown. Statistics from IBM's ISPF and Fujitsu's PFD, SSI (System Status Information), program attributes, and statistics and flags from IMS ACBLIB, REFERAL and FORMAT libraries are also formatted and displayed. If the userdata has an unrecognised format then the userdata halfword count is reported.

Q: Does REVIEW show long member names?
A: When an unconcatenated PDSE program object library is REVIEWed, the member list can show aliases even if the alias name is longer than eight (8) bytes. Other program object directory entry userdata items are also shown, such as Program Management version, bind date, time and job, and DLL enablement status.

Q: Why isn't the bind date/time/job visible for some members even with DFSMS/MVS 1.3 or later data management software?
A: Program Management Version 2 format program objects were introduced with DFSMS/MVS 1.3, and 1.4 introduced the Program Management Version 3 format. The bind date/time/job items were added to the directory entry with version 2. If you have any program objects bound with pre-DFSMS 1.3 Binders then these fields will not be present for those members. Further, if the program object was copied from a PDS load module then it will be a Version 1 format program object regardless of the level of system software.

Q: Is the RMODE=24 program size total segment-aware?
A: Yes. When program objects have more than one segment, only segments which must reside in 24-bit addressable storage are counted for the library RMODE=24 program size total on the member list END line.

Q: What search facilities does REVIEW have? (Updated for R37)
A: REVIEW has several FIND commands to search for specific data. The search can be case-sensitive or case-insensitive. Picture mask codes can be employed for generic searches. Whole records may be searched, or just one column, or a column range can be specified. The search may be forward or backward. The search can start from the current location or an extremity of the file. Records containing the data may be excluded from the display or the only records displayed. The data to be searched for may be a specific or generic character string, or specific hexadecimal data, or a specific SMF record type optionally including sub-type. Text search matches can be restricted to cases where the text prefixes a word, suffixes a word, or is a word.

Q: Can a whole library or library concatenation be searched?
A: Yes. Such a search is instigated from the member list display. Only tagged members are searched, except if no members are tagged whereupon all members are searched. The search can be further restricted according to member name mask. Members with data causing a search match are tagged, and highlighted in the display. Subsequent searches can be performed without resetting the tag status to locate members containing all of a number of disjoint search strings. A progress bar reports the current status during a search.

Q: Can the data set name of a member in a concatenation be ascertained?
A: Yes. For example, suppose an ISPF panel name of 'FREDPANL' was displayed after using 'PANELID ON' in ISPF. Issuing 'TSO REV ISPPLIB(FREDPANL) F'  causes REVIEW to display the member contents, with the complete data set name shown in the top left corner of the screen.

Q: What data extraction facilities does REVIEW have?
A: REVIEWed data can be "cut" (or more accurately "copied") to an output sequential file. Data output starts from the current location. It can run till end-of-file. It can be restricted by output record count. Only records eligible for display are written, so "FIND ALL" and related commands can be used to restrict output based on data content. ASCII data REVIEWed with 'ASCII ON' is translated to EBCDIC before being written. And then there are all the ways to process PDS member data from the member selection list.

Q: How can members be extracted from partitioned files?
A: A few methods of sequentialising data on a member basis can be initiated from the member display list. To simply combine the data in all or seleted members into one file use SEQLOAD. To copy members with control statements so that the members can be recreated use OFFLOAD. To extract object "decks" from load modules use DELINK.

Q: Can data extracted from PDSs by REVIEW be reloaded by REVIEW?
A: To reload data created by an OFFLOAD operation use PDSLOAD. Although this operation is initiated from the REVIEW member list display, REVIEW will call another program to carry out the process.

Q: What other programs are needed to make REVIEW fully functional?
A: To reload data in a PDSLOAD operation REVIEW will call either PDSLOAD (for RECFM F and V) or REVLMOD (for RECFM U). (Note that the 1999 (or later) version of PDSLOAD which supports DDname overrides is required by REVIEW.) To perform the DELINK function REVIEW will call the DELINKI program. DELINKI requires the BPAM support routine DWNSPDSR. To format SMF records REVIEW calls REVSMF. To show pictures on graphic terminals with vector graphics REVIEW calls GDDM base routines. Ideally, the GDDM.SADMMOD or equivalent library should be in the system linklist. To invoke ISPF services REVIEW calls ISPLINK. To invoke PFD services REVIEW calls PFDLINKX. To unzip data from a zip archive REVIEW calls MINIUNZ as made available from the JCC goodies and updates page.

Q: Can data extracted from PDSs by REVIEW be reloaded by other programs?
A: For RECFM F and V files the sequential file created by OFFLOAD is a superset of the IEBUPDTE method. IEBUPDTE itself can only write fixed length records with LRECL in the 1 to 80 (inclusive) range. Other programs which can reload this data include PDSLOAD and UPDTE for the CBT file collection, and StarTool from Serena. For RECFM U (load modules) only REVLMOD can reload the data.

Q: What are the effects of an OFFLOAD/PDSLOAD cycle?
A: ISPF statistics would lose the last modified seconds value, and the creation and last modified dates are mapped into the 1966-2065 century if the Y2K-ready version of PDSLOAD is installed. (In fact, this is one way to get ISPF stats corrected if they were the result of a PDS reload with a non-Y2K ready process.) PFD stats would also be converted to ISPF stats, and the current record count in the ISPF stats is forced to the correct value. If the output file was a PDS (not a PDSE) the members would be physically located in the order of the member list displayed at the time of the OFFLOAD was issued. All members, including load modules, should compare byte-for-byte equal with their original counterpart on a record-by-record basis.

Q: Does an offload preserve aliases?
A: Only if the member display was sorted into TTR order when the offload started. "Orphan aliases" (aliases with no corresponding real member) are not preserved.

Q: Are all delinker facilities available from REVIEW?
A: No, REVIEW only uses the DELINKI program to get a linkage editor (program binder) SYSLIN input file which is as complete as possible in order to be able to recreate the original program. Other functions of David Noon's delinker (written in PL/I) such as the ability to wrap MCS statements around the object files, update one subroutine in all programs, extract the entry point CSECT only, and others, are not accessible from REVIEW.

Q: Are the compilation and link edit details of programs available?
A: Yes. Select the program entry using the 'H' selection code. For load modules this just selects the member for REVIEW and scrolls right to the CESD format area. For program objects in PDSEs and UNIX files this initiates a dialog with the Program Binder to extract these details.

Q: Can data beyond I/O errors be displayed and extracted?
A: Yes. Use the NEWTOP subcommand to specify a top-of-data location which is after the I/O error. NEWTOP can also provide access to data beyond an end-of-file marker, including deleted PDS (but not PDSE) members.

Q: How does REVIEW decide the record length to use for UNIX files? (Updated for R36.5)
A: Files selected with an 'A' selection code are deemed to be ASCII text files with a maximum record length of 256. For the 'S' and '/' selection codes all files with a size that is a multiple of 4096 are treated as having fixed-length 4096-byte records. Files with a size that is a multiple of 80 have the first 80 bytes examined for code points outside the x'40' to x'FE' range other than x'15'. If any such code point is found then the file is treated as having fixed-length 80-byte records, otherwise the file is treated as an EBCDIC text file with a maximum record length of 80. Other files are considered to be EBCDIC text files with a maximum record length of 256. The term "EBCDIC text file" means that an EBCDIC NL character (x'15') will trigger a new line. The term "ASCII text file" means that an ASCII LF character (x'0A') or an ASCII CRLF string (x'0D0A') will trigger a new line.

Q: What are the limitations of UNIX file support?
A: REVIEWing data more than 4GB from the start of the file will not function correctly. Specifically, REVIEW only employs four bytes to checkpoint the RBA of records, so any action which causes the traversing of the 4GB "line" may not work reliably or at all.

Q: Are SUPERUSER privileges used? (New for R38.2)
A: Yes, when REVIEW is used to browse a UNIX file and the user is permitted to switch to SUPERUSER by the security component the user can browse any UNIX file.  The effective UID is always the real UID whenever REVIEW invokes an ISPF file service such as Browse or Edit.

Q: Which bytes are counted in the BOTTOM OF DATA line byte count? (Updated for R36.5)
A: The byte count shown on the BOTTOM OF DATA line only includes data bytes and not control bytes. Specifically, bytes in BDWs and RDWs (for variable-length record files), new line triggers (in text UNIX files), and bytes in CIDFs, RDFs and spare CI space (for non-linear VSAM) are not counted. For EBCDIC text UNIX files, the BOTTOM OF DATA line byte count should be less than the size indicated in the directory entry by the number of NL characters present in the file. For ASCII text UNIX files, the BOTTOM OF DATA line byte count should be less than the size indicated in the directory entry by the number of LF characters and CRLF strings present in the file.

Q: Where can all the program source code be obtained?
A: The source code of REVIEW and all related modules with names beginning with 'REV' is in CBT file 134. The source of PDSLOAD is in CBT file 93. The source of the DELINKI package is in CBT file 90. The source to MINIUNZ (and MINIZIP) is available by request.

Q: What Operating Systems will REVIEW work on? (Updated for R38)
A: This is controlled by the generation options in the REVGEN source member. REVIEW requires the High-Level Assembler and an OS/390 2.7 or later MACLIB to assemble, but the resulting executable is intended to work on all MVS and successor operating systems from IBM, and F4 and successor operating systems (eg. MSP) from Fujitsu. &SYSSPLV is set to '1' to ensure generation of pre-XA compatible code which avoids a S0C4 abend on pre-XA (and MSP) systems after a PA1 (due to STAX macro expansion differences).

Q: Does REVIEW work on MVS 3.8J?
A: Yes. Logic changes to correct certain problems under MVS 3.8 such as S0C1 abends and screen handling errors were implemented in Release 35.3. Note that this relates to running pre-compiled object code under MVS 3.8, and not to assembling REVIEW on MVS 3.8 with the IFOX00 Assembler. On systems without ACF/VTAM (the GTTERM macro is not supported) REVIEW assumes support for extended highlighting, colour (codes F1 to F7 inclusive) and graphic escape (to access the APL character set) which most modern 3270 emulators support. ACF/VTAM is required to perform a Read Partition (Query).

Q: Does REVIEW work on MVT?
A: No, but a porting of some functions would be possible. The &MVS switch should be set to 0 for pre-MVS TSO systems (which means MVT and SVS). The source would probably have to be reassembled on an OS/390 system and link edited with 'DC', and the load module copied to the MVT system. Recent (ie. since 1984) additions to REVIEW code have not always employed the switch at all places where conditional assembly should take place, so be prepared for some problems. REVIEW might just now use too much storage to run under MVT, but this will of course depend on the TSO REGION size. Logic paths using the "new" GETMAIN/FREEMAIN SVC (SVC 120) may cause additional problems. There may also be the question of TCAM vs. VTAM support to be considered. REVIEW also uses several TSO/VTAM terminal control macros which issue SVC 94. Speaking of MVT, the REVCAT program may be of interest to assist with the administration of OS catalogs (aka SYSCTLG data sets or CVOLs).

Q: Any tips for compiling REVIEW?
A: Currently, the High-Level Assembler is required to assemble REVIEW. Use the supplied job streams (the member names end with a '$') as templates to help ensure that the correct assemble and link edit parameters are used. REVIEW recursive session detection logic depends on REVIEW being marked as reentrant, which also ensures that one copy of REVIEW in storage is sufficient for all nested REVIEW sessions. If the IEWBUFF macros do not assemble correctly on systems before OS/390 2.7 try replacing VERSION=3 with VERSION=2.

Q: Any tips for installing the TSO HELP members?
A: Unless locally customised, the supplied REVIEW# member should be copied to the appropriate SYSHELP concatenation library with a member name of 'REVIEW' and aliases of 'REV', 'REVED' and 'REVVSAM', so only one copy of the member contents physically exists in the HELP library. The RENAME command can be used to assign aliases but it requires exclusive access to the library. Unless you have a method available which can assign aliases to members with shared allocation, you may need to use an intermediate data set to create the desired member structure before copying the member and aliases into the permanent HELP library. Ensure you are familiar enough with ISPF option 3.3 to be able to copy members and aliases without creating "orphan" aliases. REVIEW can be used to check that aliases have the same TTRs as the real member. The same considerations apply to the TSO HELP of the 'FSHELP' command.

Q: Any tips for "cutting" data using REVIEW?
A: Understand the difference between the COPYOUT and APPEND commands. In particular, if you wish to accumulate multiple "cuts" into one file, use 'CUT' for the first "cut" and 'ADD' for subsequent "cuts". 'COPYOUT' or 'CUT' will overlay all previous output data, while 'ADD' or 'APPEND' or 'TACKON' functions like DISP=MOD (ie. opens the output file for EXTEND).

Q: Any further tips for using REVIEW?
A: If learning all the subcommands seems a bit overwhelming, try to at least understand the operands available of the REVIEW command itself, particularly the various functions of the 'DATA' operand. And don't forget to customise the display colours and PFKs to suit your terminal and your work patterns, as appropriate.

Q: What support is available for REVIEW?
A: REVIEW is public domain software and its use and/or installation does not require that any sort of monetary payment or consideration be made. Accordingly, no warranties are given about usefulness or functionality of this software. The source code is available for anyone to audit. Having said that, the current maintainer of REVIEW may be contacted should the need arise to ask questions about REVIEW, or provide some assistance for debugging or enhancing REVIEW. Email contact details are in CBT file 134. Before seeking technical support for REVIEW please ensure you are using the latest release of REVIEW. If a bug is still present in the latest release then at least the program offsets will match my copy.

Q: What is the easiest way to determine the release of REVIEW in use?
A: The load module eyecatcher string contains the release number, but on numerous occasions claims of bugs not fixed in a new release have turned out to be that even though a user has the new release an older release is still being run. To find out the release of REVIEW in use first REVIEW a file and then issue the 'KEYS' or '?' command (without the quotes) which shows the current PF key assignments. The release is shown in parentheses on the right just under the "ruler" line. Note that 'KEYS' is also an ISPF command, so if REVIEW is running as an ISPF application be sure to use '?'.

Copyright © 2003 Prycroft Six Pty Ltd - ABN 17 006 544 636 - All rights reserved.
webmaster@prycroft6.com