开云体育

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Greg Price
Sent: Sunday, January 3, 2021 07:26 AM
To: [email protected]
Subject: [H390-MVS] REVIEW/RFE profile management change proposal

Hi,

I am considering a change to where REVIEW/RFE stores its profile data, and I thought I should probably mention the idea in case anyone can think of any show stoppers. (I can't.) Accordingly, I am soliciting feedback from anyone with pertinent thoughts on the matter.

When first heading off in the "let's have stored REVIEW profile data"
direction circa 1990, I used the ISPPROF DD because I could guarantee (pretty much) that all users would have such a DD allocated. (The only problem about using REVIEW without a profile data set is that changed settings will not be remembered across sessions.)

When the Hercules and free MVS situation unexpectedly (at least, for me) arose again around the time of the change of millennium, I decided I would use REVPROF as the DD name on MVS/370 because there was no ISPF generally available, and for all I knew any ISPF-type package that may become available may want to use the ISPPROF DD name to allocate a PDS (or whatever) common to all users, which of course would render the file unsuitable for REVIEW which relies on static member name(s) to store user-specific data.

For those that don't know, SPF 2.2 dynamically allocated hard-coded (and therefore system-wide) data set names for panels (known as menus at the time), messages, skeletons, and profiles. Your profile was stored in a member which had your user ID as its name. IIRC, the high level qualifier for these data set names was SPF22.

As things have turned out, Wally's ISPF package has eventuated, and it uses ISPPROF for profile data which is allocated to a PDS with fixed-length 80-byte records (as far as the VTOC entry is concerned), which matches IBM's ISPF in this regard.

So, I am now considering that from Release 50.0 onwards, the REVIEW/RFE package will use the ISPPROF DD to store its profile data on all OS levels. This will mean I can delete the "use REVPROF instead of ISPPROF if the OS is pre-ESA" logic.

On ESA, OS/390 and z/OS systems, the ISPPROF DD has always been used and to my knowledge there has never been any problem with interfering with ISPF processing. Once a given REVIEW/RFE profile member has been created, it is updated in place (unless it needs to be enlarged) so ISPPROF disk space management is generally not an issue.

If your REVPROF and ISPPROF data sets are different, the migration action would be to copy the REVPROF members into the ISPPROF data set, and you should be good to go.

In due course, there will be the clean up action of removing the unnecessary allocation of the REVPROF data set, and deleting any REVPROF data sets that are no longer required, but all that can wait a bit until it's all bedded down.

Does anyone think this is a bad idea?

If so, why?

Thanks!

Cheers,
Greg







--
This email has been checked for viruses by AVG.