Re: REVIEW/RFE profile management change proposal
On 04/01/2021 16:51, Juergen wrote: Hi All
Wally surely means me, and yes, his ISPF will definitively be in the next TK4- update. It will completely replace TSOAPPLS, my "poor men's dialog manager". Sorry, that it takes me so long to get this done. However, my online system at wotho.ethz.ch:3270 has the integration already in place and it can thus be used as a preview of the new look and feel.
Cheers
´³¨¹°ù²µ±ð²Ô Did try and connect a few days ago and just now but with NO response using x3270 and worth04-ethz.ch:3270 Will have to wait in anticipation for .9. Vincent
|
Re: REVIEW/RFE profile management change proposal
Hi All
Wally surely means me, and yes, his ISPF will definitively be in the next TK4- update. It will completely replace TSOAPPLS, my "poor men's dialog manager". Sorry, that it takes me so long to get this done. However, my online system at wotho.ethz.ch:3270 has the integration already in place and it can thus be used as a preview of the new look and feel.
Cheers
´³¨¹°ù²µ±ð²Ô
|
Re: REVIEW/RFE profile management change proposal
Hi Wally; On 04/01/2021 04:29, Wally Mclaughlin wrote: Greg,
I think this a great idea.
In my last discussion with Volker, our plan is to incorporate ISPF into the next TK4 release. Who and TK4 ? Vince Wally
|
Re: REVIEW/RFE profile management change proposal
On 2021-01-04 3:29 PM, Wally Mclaughlin wrote: I think this a great idea. Great, Wally - glad to hear you think so.
In my last discussion with Volker,
Freudian slip? :) our plan is to incorporate ISPF into the next TK4 release. Excellent news! Cheers, Greg
|
Re: REVIEW/RFE profile management change proposal
Greg,
I think this a great idea.
In my last discussion with Volker, our plan is to incorporate ISPF into the next TK4 release.
Wally
toggle quoted message
Show quoted text
-----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.
|
Re: REVIEW/RFE profile management change proposal
On 2021-01-04 3:47 AM, pjfarley3 wrote: Sounds good to me. Thanks, everyone!? I shall take that as the green light to go ahead... Cheers, Greg
|
Re: REVIEW/RFE profile management change proposal
Greg,
Sounds good to me. I can't think of any downside except if Wally's ISPF is not integrated into the next TK4 release.
Peter
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Greg Price
Sent: Sunday, January 3, 2021 7: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. <Snipped> 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 --
|
Thanks, It appears? YES worked.
On Sunday, January 3, 2021, 8:27:27 AM CST, Mark Waterbury <mark.s.waterbury@...> wrote:
I ran a web search for "ICH702A ENTER PASSWORD TO ACTIVATE RACF JOB" and found several links to IBM RACF documentation.
It seems to suggest you MIGHT be able to reply with "YES" as a "default" password.??? Try that?
|
Re: REVIEW/RFE profile management change proposal
Hello Greg, Am 03.01.2021 um 13:26 schrieb Greg Price <procegrog@...>: Does anyone think this is a bad idea? I think this is a good idea. Less clutter! :wq! PoC
|
Note that any special user can change that password without having to know it ;-)
|
I ran a web search for "ICH702A ENTER PASSWORD TO ACTIVATE RACF JOB" and found several links to IBM RACF documentation.
It seems to suggest you MIGHT be able to reply with "YES" as a "default" password.??? Try that?
|
Re: REVIEW/RFE profile management change proposal
Hi Greg,
This is a marvelous idea. I am a user of Wally's ISPF and RFE and of course my own RPF.
Now I have allocated REVPROF and ISPPROF, but these ddnames point to the same data set.
So,? its fine to use the ISPPROF ddname.
RPF is not bothered by this change, because RPF uses a VSAM profile cluster to store the defaults.
BTW: If you change in Wally's ISPF the option 2 panel from? REVED into RPFED, you get the RPF Editor.
Thanks for your great product.
Cheers,
Rob
|
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
|
yes
It's somewhere in the RACF manuals, but right now I can't remember in which one.
Cheers,
Peter
|
Re: Latest version of Review ABENDs
On 2021-01-03 11:12 AM, Charles Bailey wrote: l fcd28. l(16)
?0FCD28.? F0F1F2F3 F4F5F6F7 F8F9C1C2 C3C4C5C6
?TEST
Offset +578 looks like an EBCDIC character string, '0123456789ABCDEF', not code.? So, it looks like the 0C1 was caused by an errant branch to the wrong address. Charles, Hmmm, interesting... I guess you are running a different Hercules and MVS combo to the system I tested on to recreate the problem.? An old version of ZP60023 which added BSM support to the PC FLIH, perhaps?? Still, the main thing is that it runs correctly when the correct code is in place. Thanks for the feedback! Cheers, Greg
|
Re: Latest version of Review ABENDs
Greg,
I tried running RFE under TEST and got some different results than what you show in that graphic.
READY
test 'sys2.cmdlib(rfe)' cp
ENTER COMMAND FOR CP
rfe
TEST
go
RFE ENDED DUE TO ERROR+
TEST
?
SYSTEM ABEND CODE 0C1 REASON CODE 001
TEST
where
FCD28. LOCATED AT +578 IN RFE .REVPROF UNDER TCB LOCATED AT 9A64D8.
TEST
l fcd28. l(16)
0FCD28. F0F1F2F3 F4F5F6F7 F8F9C1C2 C3C4C5C6
TEST
Offset +578 looks like an EBCDIC character string, '0123456789ABCDEF', not code. So, it looks like the 0C1 was caused by an errant branch to the wrong address.
I tried running that AMASPZAP job step and now RFE works! It's good to have RFE running again. Thanks for the quick response and fix.
Charles Bailey
toggle quoted message
Show quoted text
On 2021-01-01 22:30, Greg Price wrote: On 2021-01-02 9:31 AM, Charles Bailey wrote:
READY
rfe
RFE ENDED DUE TO ERROR+
READY
?
SYSTEM ABEND CODE 0C1 REASON CODE 001
READY The next thing to enter here is
TEST
then issue WHERE at the TEST prompt. END will exit TEST back to READY.
Attached is a screen shot of a TEST session I did to produce the sort of information that may assist diagnosis.
Of course, I could not reproduce the error on my TK-based system because I was running "380" to debug some glitch to placate the demands for XA compliance from a certain quarter. Anyway, a testing mod remained in the code base which resulted in the S0C1 on strictly 370 "hardware".
A S0C1 abend is an operation exception. The first thing to find out is whether there is an unsupported instruction in the code stream, or if there has been a wild branch to an incorrect location. The attached screen shot shows it was the former. Of course, the clearly superior way to capture the circumstances of the abend would be to use MVSDDT. Unfortunately, in my z/OS-based job I don't have MVSDDT so I continue to reinforce my habit of using TEST. (Naughty Greg!) And naturally IPCS comes in for a fair bit of use on z/OS as well.
Still, that's not why you called...
Here is a job step you can tailor to apply a fix:
//STEP1 EXEC PGM=AMASPZAP
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=SYS2.CMDLIB
//SYSIN DD *
NAME REVIEW REVIEW
IDRDATA S0C1-FIX
VER 02C8 4700
REP 02C8 47B0
/*
Cheers,
Greg
|
I did a RVARy LIST followed by RVARY ACTIVE at TSO prompt then I get Enter RACF password on the console.
Does anyone know what it might be or how to find out?
I tried secret and it was not it.
17.42.01 TSU00042 *09 ICH702A ENTER PASSWORD TO ACTIVATE RACF JOB=P390
|
Re: Latest version of Review ABENDs
On 2021-01-02 9:31 AM, Charles Bailey wrote: ?READY
rfe
?RFE????? ENDED DUE TO ERROR+
?READY
?
?SYSTEM ABEND CODE 0C1?? REASON CODE 001
?READY The next thing to enter here is TEST then issue WHERE at the TEST prompt.? END will exit TEST back to READY. Attached is a screen shot of a TEST session I did to produce the sort of information that may assist diagnosis. Of course, I could not reproduce the error on my TK-based system because I was running "380" to debug some glitch to placate the demands for XA compliance from a certain quarter.? Anyway, a testing mod remained in the code base which resulted in the S0C1 on strictly 370 "hardware". A S0C1 abend is an operation exception.? The first thing to find out is whether there is an unsupported instruction in the code stream, or if there has been a wild branch to an incorrect location.? The attached screen shot shows it was the former.? Of course, the clearly superior way to capture the circumstances of the abend would be to use MVSDDT.? Unfortunately, in my z/OS-based job I don't have MVSDDT so I continue to reinforce my habit of using TEST.? (Naughty Greg!)? And naturally IPCS comes in for a fair bit of use on z/OS as well. Still, that's not why you called... Here is a job step you can tailor to apply a fix: //STEP1 EXEC PGM=AMASPZAP //SYSPRINT DD SYSOUT=* //SYSLIB DD DISP=SHR,DSN=SYS2.CMDLIB //SYSIN DD * ?NAME REVIEW REVIEW ?IDRDATA S0C1-FIX ?VER 02C8 4700 ?REP 02C8 47B0 /* Cheers, Greg
|
Re: Latest version of Review ABENDs
Charles Bailey wrote: [...] Now I wish I had made a backup of version 49.2 before
upgrading. Hi Charles! I'm not going to berate you regarding the importance of backing your system up before making major changes to it. You've already learned that lesson. :) Rather, I am simply going to use this as an opportunity to remind/inform everyone that your situation is the perfect argument for "The Advantage of Shadow Files": * "With the use of shadow files you can reconfigure your guest without worrying about whether the new settings might render your guest unusable. Simply create a new shadow file before you do your reconfiguration. If something goes wrong, simply exit Hercules and then delete that set of shadow files. You'll be right back to where you were before you made your changes! Then you can simply try again. Once you are satisfied that your changes are good, you can then do a "sf-*" backwards merge (see further below) to "commit" your changes." Shadow files requires the use of Compressed CKD dasd images however (CCKD/CCKD64), not regular uncompressed CKD images. Use Hercules's dasdcopy/dasdcopy64 to convert your dasds from CKD/CKD64 to CCKD/CCKD64. Then simply e sure to specify the "sf=xxxxx" option on all of your dasd statements in your Hercules configuration file. Using shadow files is easy and helps a LOT when it comes to making backups and for performing experimental system changes like you tried to do. If you have any questions or need any help regarding their use, feel free to ask your questions on the main Hercules forum and I'm sure more than one person will be willing to help you with them. Using them is really very easy and painless once you get into the habit of using them. HTH! -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Latest version of Review ABENDs
I decided to update some of the software on my TK4- system, which has been running fine for about 2.5 years. I was running Review 49.2, which ran without problems. I attempted to upgrade to version 49.9.
Uploaded rev370ld.xmi, revdata.xmi and revhelp.xmi in binary using IND$FILE in Vista.
Executed jobs $REVC370, LOADHELP and LOADLOAD. All ended with MAX COND CODE 0000
Now, when I try to start RFE I get this:
READY
rfe
RFE ENDED DUE TO ERROR+
READY
?
SYSTEM ABEND CODE 0C1 REASON CODE 001
READY
I tested the integrity of rev370ld.zip with 7zip and it found no errors. I didn't get any errors when I extracted rev370ld.xmi. No errors in any of the installation steps as mentioned above.
Now I wish I had made a backup of version 49.2 before upgrading. Is there somewhere that I can download a previous version, such as 49.2, so I can at least get something working again?
Thanks,
Charles Bailey
|
Rob Prins
Peter Jansen
