Hi,

Just to announce that Release 50.0 of the REVIEW/RFE package is now available from




The release notes are viewable at




Cheers,
Greg

Hello Greg,

Am 01.05.2021 um 08:52 schrieb Greg Price <procegrog@...>:

Just to announce that Release 50.0 of the REVIEW/RFE package is now available from

Cool, thanks a lot!!

:wq! PoC

Thanks for your great work Greg.
I've just installed the new version.

Cheers,
Rob

I was going to download this, and also check the notes to report a bug but it seems Greg's site is down. Hopefully just temporary.

Anyway, the "create" command in edit mode will not allow you to name a member with an "&" in the name. But it will let you rename it to have an "&". While I don't have access to ISPF, I am led to understand that this is not allowed. So it's either breaking the rule intentionally but not consistently, or breaking the rule unintentionally.

开云体育

On Tue, 18 May 2021, at 10:30, Greg Price wrote:

Thanks for the bug report...

Is it actually a bug though?

Just because ISPF limits member names doesn't mean that member
names cannot legitimately have strange characters in them. See eg:



ISTR that eg the members stored in the SMPMTS (or maybe one of
the other SMP/E work PDSs) were in essence just given binary
numeric 'names' - which looked odd in ISPF member lists but was
clearly useful from SMP/E's point of view.

--
Jeremy Nicoll - my opinions are my own.

On 18/05/2021 8:03 pm, Jeremy Nicoll wrote:

Is it actually a bug though?

Well, I'm claiming it is not a coding defect, but you could argue it is a design defect depending on what you think the design goal should be.

As was alluded to, browse SYS1.SMPCDS and SYS1.SMPACDS and SYS1.SMPSCDS and you can see how SMP freely uses whatever member names it likes without regard to the "character set".? And despite converting the first 2 of those data sets to VSAM "consolidated software inventories", SMP/E continues to use the SCDS ("saved CDS entries") to this day.

If you think that TSO productivity packages such as PDF and RPF and RFE should really be assisting users to create files that work well with TSO services (IKJPARS, IKJDAIR et al) and JCL etc. then you might consider it a bug. If you think it is a fun little quirk to be used a few times a decade for giggles then you might not - you might think the bug is that all RFE facilities processing PDSs do not support the "extended" member name ability.

Cheers,
Greg

If ISPF/PDF does not allow certain characters in member names, there is a good reason for that.? I doubt that JCL would allow it either.

The only legal characters in member names are:?

? ?First character must be A-Z or @, #, $ ...

? ? Second thru 8th character must be any of the above plus the digits 0-9 ...

As far as I know, those have always been the "rules" dating back to OS/360 ...

Mark

I forgot to mention this -- just because SMP may be using "odd" member names does not mean they are "legit" -- SMP is a special case; those datasets (CDS, ACDS, etc.) are special and IBM did not want you poking around in there ...

I'm sort of new to all of this, but it seems clists do not work with members starting with "$$" as opposed to just "$". Also I am assuming since clists use "&" as a variable indicator, it might simplify the parser.

On Wed, May 19, 2021 at 09:34 AM, Mark Waterbury wrote:

If ISPF/PDF does not allow certain characters in member names, there is a good reason for that.? I doubt that JCL would allow it either.

You would be wrong. One would be amazed as what you can put in various JCL fields (for example, file names) if you quote them. If one chooses to RTFM, it's even documented.??
?

?A reading from the Book of OS/VS2 MVS JCL (GC28-0692-5):

If a data set name includes special characters as part of the name (the characters do not have special significance to the system), you must enclose the name in apostrophes (5-8 punch). If one of the special characters is an apostrophe, identify it by coding two consecutive apostrophes, for example, DSNAME='DAYS"END'.

When I was talking to someone about how Clarkson College (our mutual alma mater) had renamed their IEH* & IEB* utilities and then front-ended them with a security wrapper under the original names, they noted that some shops renamed the modules to lower case.?

-ahd-?

p.s. Amazing what forcing IEHLIST?to core dump (odd how that SYSPRINT DD had zero tracks allocated to it!) can show a person.? The system programmer knew I had a list of the real utility module names, and it drove him nuts.? Ah, the glorious results of a misspent youth

I've installed the latest and greatest version of REVIEW (50.3), and quoting the help file:

FORMAT? - Format file data according to Assembler data definition?source code in the nominated member of the REVFMTS file.?VTOC entries can be formatted without the REVFMTS file.? ? ? ? ?

Does a file to connect to this DDNAME actually exist, or is it in the same class as Unicorns and easily configured VTAM setups?

-ahd-

Drew Derbyshire wrote:

[...]

you must enclose the name in apostrophes (5-8 punch).

Which is a single apostrophe ('):

If one of the special characters is an apostrophe,

(i.e. a 5-8 punch)

identify it by coding two consecutive apostrophes,

(i.e. two consecutive 5-8 punches)

for example, DSNAME='DAYS"END'.

Which, when typed into an HTML email (as opposed to a PLAIN TEXT email), ends up causing some email clients to replace them with a single double-quote character instead, leading to confusion/misinformation.

OR... It could of course also have been the fault of whatever program OCR'ed the original manual, which I'm guessing was more than likely coded correctly with two single-apostrophe characters, but which upon being OCR'ed, ended up being interpreted as a single DOUBLE-quote character instead, which you then simply copy & pasted into your HTML email as-is.

But for the sake of clarity/correctness, the shown example SHOULD actually be:

DSNAME='DAYS''END'


Yeah, I'm anal. So sue me. ;-)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

I'll see your retentiveness and? raise you the original scanned text:

Yea, that's a double quote in the middle, not two apostrophes.? In the manual's font it s more obvious, because they curl differently and are less bold.

-ahd-

p.s. We're programmers — all the good ones are?retentive.

开云体育

I've installed the latest and greatest version of REVIEW (50.3), and quoting the help file:

FORMAT? - Format file data according to Assembler data definition?source code in the nominated member of the REVFMTS file.?VTOC entries can be formatted without the REVFMTS file.? ? ? ? ?

Does a file to connect to this DDNAME actually exist, or is it in the same class as Unicorns and easily configured VTAM setups?

If you have a data set containing records that - when browsing the data set with REVIEW - you want formatted such that the names of the record's items are shown across the top, and underneath are the values of those items from the records that are on screen, and you have the structure of the record described by a DSECT or similar assembler code residing in a PDS allocated to the REVFMTS DD, then you can issue the command

FORMAT XYZ

where XYZ is really the name of the member containing the assembler source, and the records will be formatted accordingly.? Fields of F and H types will be converted to decimal - but I did not bother with floating point support, so they will be shown in hex.

Assembler source for the record layouts pertaining to your application of interest are not provided in the REVIEW/RFE package.

And then there's the matter of more sophisticated assembler source easily fooling my crumby source code parsing.? Still, if you keep it simple it should work.


If browsing a VTOC with a command such as

REV 'FORMAT4.DSCB' VOL(PUB001)

where PUB001 is replaced by the actual volume serial with the VTOC to be browsed, then you do not need to have the layout of the format-1 DSCB in assembler source in a member of a PDS allocated to the REVFMTS DD to issue

FMT ON

and have the various DSCB fields broken out.? Note that all DSCBs are treated as if they are format-1 (or format-8) DSCBs.

If REVIEWing a VTOC, and the primary input area is primed with TSO REV and the cursor is placed on a line showing data from a format-1 DSCB, then that data set will be browsed by REVIEW even if the cursor is not on the actual data set name, and even if the data set name is not on-screen at the time.

The above represents the design goals that more or less worked at one time - I have not tested some of these aspects lately and so if you find anything that no longer works then please let me know.

One thing I do use a lot that still works is browsing a data set nominated by the cursor location when the entire data set name is visible on the screen line.? Sometimes I want to look at another member in the same PDS I am already looking at without exiting the member being viewed.? Since I usually forget to use the PFK I have set to TSO REV, I type in TSO REV and then move the cursor up one line, and press <enter>.

Moving the cursor up 1 line (to the actual top line of the screen) places the cursor over the name of the data set being browsed.? Note that in this particular case, this still works even if the data set name has been temporarily replaced by a message (presumably reporting results from the previous command).

When using IBM's ISPF and editing JCL, sometimes I want to check whether a particular data set already exists or not.? In REVEDIT with DSNC ON, the data set name JCL highlighting indicates this, but this is not the case with ISPF.? I sometimes elect to attempt a point-and-shoot REVIEW of the data set as a quick way to find out whether I need DISP=NEW or DISP=OLD.

Cheers,
Greg