FAQ for the REVIEW TSO Command Updated for Release 41.0
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
|