¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

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


Re: RACF Password?

 

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

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





RACF Password?

 

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





regards;

Rahim
??



??


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


Re: Don't use ISAM

 

Thanks Jay, I was asking about Ed Liss affirmation, because I wanted to use the examples straight from? the manuals, I know the interface works very well, it's a terrific work, but since I'm only interested in the concepts of Vsam, not in developing a particular application I'd rather use a compiler that needs no interface I've been using idcams and it works for me.?


Re: Working with ISAM Data Sets

 

Hello Jay,

Am 31.12.2020 um 15:41 schrieb Jay Moseley <JayMoseley@...>:

I have updated my page on the ISAM/VSAM Interface Program to include a simple example using COBOL programs:
Thanks a lot!! I¡¯ll give it a shot as soon as I have sorted out my RAKF-Woes. :-)

:wq! PoC


Re: Don't use ISAM

 

On Thu, Dec 31, 2020 at 7:45 AM carlos feldman <carlfelster@...> wrote:

TK4- PL/I Compliles is PL/I(F), which certainly does not support VSAM, but ISAM. Is there another compiler available ?
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


Re: Don't use ISAM

 

On 12/31/20 7:45 AM, carlos feldman wrote:
TK4- PL/I Compliles is PL/I(F), which certainly does not support VSAM, but ISAM. Is there another compiler available ?
Carlos,

The ISAM/VSAM Interface will work with PL/I programs, and RPG programs as well. The IIP is managed by MVS 'under the covers' and is invoked when a DD statement is processed linking a DCB that is ISAM (on the application program side) to a VSAM cluster.

There is nothing special to be done in the application program code, simply code as you would for ISAM and when the OPEN code is executed the IIP will be loaded to handle all requests to/from the dataset (which is a VSAM dataset).


Re: Working with ISAM Data Sets

 

Patrik, and others interested:

I have updated my page on the ISAM/VSAM Interface Program to include a simple example using COBOL programs:


Re: Don't use ISAM

 

TK4- PL/I Compliles is PL/I(F), which certainly does not support VSAM, but ISAM. Is there another compiler available ?


Re: Working with ISAM Data Sets

 

Hello Carlos,

Am 27.12.2020 um 16:32 schrieb carlos feldman <carlfelster@...>:

I was using ISAM some weeks ago, It may not be my database of choice today, But I wanted to use the same tools that were used in the 60's an ISAM, and Regional are part of the basic package of Tk4-.
Thanks for your efforts and suggestions. I got a hint off-list about the so called ISAM / VSAM Interface.



"The ISAM interface allows a properly written and debugged program that processes an indexed sequential data set to process a key-sequenced VSAM dataset (KSDS) transparently.¡°

I¡¯m not yet sure which way to go, especially considering that RAKF is annoying me a lot, but this is left for another message in the Turnkey-MVS group which might be a better fit for a Turnkey-related problem.

Thanks for your feedback and examples, I¡¯ll keep them as reference!

:wq! PoC


Re: Don't use ISAM

 

Also interested in VSAM
Dear Ed,
I am a retired COBOL programmer using TK4- to practice COBOL. I definitely want to use VSAM, and I'm willing to learn API from scratch if you'll tell me how to get started
Thanks,
Bernard

On Sun, Dec 27, 2020 at 12:48 PM Ed Liss <egliss4024@...> wrote:
On Sat, Dec 26, 2020 at 12:53 PM, Patrik Schindler wrote:
Allow me to explain a few more details. I want to use TK4-, so the only COBOL compiler legally available is the MVT one. I honor Jay Moseley's work to enable using VSAM through API calls from that old compiler, but I don¡¯t wanna take this extra step in learning.
The MVT COBOL and PL/1 compilers both support ISAM without the need for an API.? ISAM can be easy to learn but has little or no utility support.? VSAM has IDCAMS which provides a lot of utility functions, such as PRINT or REPRO.


MVS Help

 

Hello,

I anyone able to help me locate what is going wrong with my
IBM360/370 simulator with MVS. I can restore the starter system. But
when I go to install the SMP patches the new SMP does not appear to
link correctly. My simulator will run VM/370, TSS/370, MTS D2 and D4
and OS/360 along with DOS/360.

Contact me off list if you wish to help and I will give you
directions to the simulator and setup files.

Rich

--
==========================================================================
Richard Cornwell
rich@...

LinkedIn:
==========================================================================


Re: Difficulties with TCP/IP and data sets

 

Pedro;

In OS/390? TCPPROF is under dataset prefix TCPIP; TCPIP has to be stopped before editting it; and the way to check your settings is from TSO command line by typing NETSTAT DEV;



Rahim


Re: Difficulties with TCP/IP and data sets

 

Well, folks. Crisis averted (for now). I was going to try Mark's solution. But, for now, Ren¨¦'s idea proved to be a savior one.?

Turns out I completely forgot about the PROCLIB dataset. After that, I've varied online the two CTCA devices and LCS works like a charm.

Thank you all for the time. This community is still the best. This site Mark indicated contains several resources that'll surely look into more carefully.

Att.,
-trp


On Mon, Dec 28, 2020 at 12:21 AM Ren¨¦ Ferland <ferland.rene@...> wrote:
On Sun, Dec 27, 2020 at 06:02 PM, Pedro Pinheiro wrote:
So, it seems to be working.

I think my suggestion does not solve the problem. On your system, TCPIP is apparently started by CENTER.PROCLIB(TCPIP) which has an explicit DD for the PROFILE with DSN=CENTER.PARMLIB(TCPPROF). So the new TCPPROF is not going to be used, despite the PARMLIB concatenation. Then, how about changing that specific DD to a dataset of your own?

Rene FERLAND, Montreal