Help make XEDIT and ISPF EDIT keystroke compatible (WAS: XEDIT Macro and Command Line Input)
Phil,
Thanks. You are right. I was trying too hard. Checking queued() was exactly
what I needed.
And yes, I am trying to get my VM and MVS environments to behave somewhat
alike. Like you said fingers get trained. And, after 30+ years my fingers are
very well trained! The problem is that over the years I have spent time in both
camps so I have issues either way I go. My co-workers laugh because
my MVS world has always understood QQ FILE. (And I always have
'autosave' turned off.)
Right now I'm starting to do more in the VM world and I find that by using
PF7/PF8 all I succeed in doing losing my place in my document.
Going the other way, I keep wanting to use X in ISPF 3.4 ... and my dataset
just disappears!
So, SCROLL is destined to be assigned to all the pf keys I expect to scroll
the screen and make it behave more like ISPF.
And I would be happy to collaborate on making this happen.
(And I know you suggested that I contact you off-list, but I'm betting we are
not the only ones that would like these capabilities. And, we are probably
're-inventing the wheel' in many cases. Perhaps, we will get some others
offering tools that they have already created.)
Bob
On Sat, Aug 6, 2011 at 7:23 AM, Phil Smith III li...@akphs.com wrote:
Bob,
You're actually trying too hard: your macro should just look at QUEUED() and
see if there's something stacked.
This is a crude example, because you probably want to do more than just a
LOCATE * for a M (like EXTRACT /SCREEN and divide by 2, then make it
'COMMAND * -'n
or some such), but:
/**/
if queued() 0 then pull op
else op = ''
if abbrev('MAX', op, 1) then 'COMMAND LOCATE *'
else 'COMMAND FORWARD' op
BTW, are you trying to do an SPF-ish environment in XEDIT? If so, please
contact me off-list -- I'd be interested in helping. Not that I think SPF is
better*, but I understand that the fingers get trained (now that I'm doing
z/OS, I find myself doing FIND instead of / in XEDIT and KEDIT sometimes!),
and it's been something that folks have talked about for a long time.
...phsiii
* Insert religious editor war here
-Original Message-
Bob mvs...@gmail.com
Subject: XEDIT Macro and Command Line Input
I'm struggling trying to write an XEDIT macro and hoping someone can help=
me=20
over a tiny stumbling block.
I want a pfkey set to a macro. ie. SET PF6 BEFORE MACRO SCROLL
And I want to be able to accept an *optional* command line parameter.
If there is always a command line parameter I seem to be able to use
READ CMDLINE to get it. However, this does not seem to work=20
when there is no command line parameter at all. I just get hung
at the READ CMDLINE until I hit enter. Also, when there is a
parameter I not only what to read it, but I want to consume it so that
it is no longer on the command line after my macro.
Is there a way to do this?
Re: Help make XEDIT and ISPF EDIT keystroke compatible (WAS: XEDIT Macro and Command Line Input)
Speaking of fingers being trained: I've always used an IBM
101 keyboard ever since IBM started using pc's and my
fingers *still* can't get used to where the arrow keys are
on it! I think they remember a 3279-3x.
My first laptop, in 2009, gave me conniption fits until I
modified a 101 keyboard to add footpads (for air
circulation) and a PS/2 to USB adapter for it so it can
bridge the laptop keyboard. A small fan to the right of my
recliner adds some extra circulation and a usb driven
portable fan goes with me when I'm traveling. So I have the
same keyboard for both the laptop and desktop. With THE as
my editor, in Xedit mode, it's just about like being back on VM!
Les
Bob wrote:
Phil,
Thanks. You are right. I was trying too hard. Checking queued() was exactly
what I needed.
And yes, I am trying to get my VM and MVS environments to behave somewhat
alike. Like you said fingers get trained. And, after 30+ years my fingers are
very well trained! The problem is that over the years I have spent time in both
camps so I have issues either way I go. My co-workers laugh because
my MVS world has always understood QQ FILE. (And I always have
'autosave' turned off.)
Right now I'm starting to do more in the VM world and I find that by using
PF7/PF8 all I succeed in doing losing my place in my document.
Going the other way, I keep wanting to use X in ISPF 3.4 ... and my dataset
just disappears!
So, SCROLL is destined to be assigned to all the pf keys I expect to scroll
the screen and make it behave more like ISPF.
And I would be happy to collaborate on making this happen.
(And I know you suggested that I contact you off-list, but I'm betting we are
not the only ones that would like these capabilities. And, we are probably
're-inventing the wheel' in many cases. Perhaps, we will get some others
offering tools that they have already created.)
Bob
On Sat, Aug 6, 2011 at 7:23 AM, Phil Smith III li...@akphs.com wrote:
Bob,
You're actually trying too hard: your macro should just look at QUEUED() and
see if there's something stacked.
This is a crude example, because you probably want to do more than just a
LOCATE * for a M (like EXTRACT /SCREEN and divide by 2, then make it
'COMMAND * -'n
or some such), but:
/**/
if queued() 0 then pull op
else op = ''
if abbrev('MAX', op, 1) then 'COMMAND LOCATE *'
else 'COMMAND FORWARD' op
BTW, are you trying to do an SPF-ish environment in XEDIT? If so, please
contact me off-list -- I'd be interested in helping. Not that I think SPF is
better*, but I understand that the fingers get trained (now that I'm doing
z/OS, I find myself doing FIND instead of / in XEDIT and KEDIT sometimes!),
and it's been something that folks have talked about for a long time.
...phsiii
* Insert religious editor war here
-Original Message-
Bob mvs...@gmail.com
Subject: XEDIT Macro and Command Line Input
I'm struggling trying to write an XEDIT macro and hoping someone can help=
me=20
over a tiny stumbling block.
I want a pfkey set to a macro. ie. SET PF6 BEFORE MACRO SCROLL
And I want to be able to accept an *optional* command line parameter.
If there is always a command line parameter I seem to be able to use
READ CMDLINE to get it. However, this does not seem to work=20
when there is no command line parameter at all. I just get hung
at the READ CMDLINE until I hit enter. Also, when there is a
parameter I not only what to read it, but I want to consume it so that
it is no longer on the command line after my macro.
Is there a way to do this?
ISPF Help panel help
Group, I have been looking through the ISPF Dialog Developer's Guide and Reference and I am having a problem with my help panel. My Primary panel has ZPRIM=YES and .HELP=SSBVPSH. From my primary panel I enter PF1 and I get my help panel. My panel looks like this: )ATTR )BODY %NOTE: MENUMSG + %ENTER+- EXIT %PF3+- EXIT + )INIT )PROC ZSEL=TRANS(TRUNC(ZCMD,'.') '*','EXIT') /*TERMINATE MENU DISPLAY*/ )END When I hit PF3 it takes me right out of my HELP panel and returns me back to my primary panel. Q). Why when I press Enter from my help screen do I get ISPP100 Panel EXIT error. Panel not found. I tried just coding EXIT, END, CANCEL and RETURN instead of the TRANS statement and I receive the same message about a Panel not found. The TRANS should be saying whatever ZCMD is, Terminate the menu display. I put a TRACE in the PROC section and it didn't like that either. I had another approach: )PROC IF (.PFKEY = PF03) ZCMD = X IF (.RESP = ENTER) ZCMD = X ZSEL=TRANS(TRUNC(ZCMD,'.') X,EXIT /* or 'X','EXIT' - Terminate Menu Display */ '','' /* Redisplay Panel on Blank */ '*','%') /* or '*','?') - Display Invalid option */ When I use '?' in my help panel and press enter it sends me to the ISPF PDF tutorial. *** Use a question mark (?) as the string. This causes the SELECT service to redisplay the menu with an invalid option message. *** When I use '%' in my help panel and press enter I get ISPP100 Panel % error. Panel not found. I Removed everything from my PROC section. ENTER takes my from my help panel to the ISPF PDF tutorial. PF3 works great. Q). How can I just redisplay my help panel or terminate my menu display by pressing ENTER? Did I miss any good ISPF books with help panel samples? Thanks in advance, Dave Dave Hansen Eagan Software Systems Branch 651-406-1208 dave.l.han...@usps.gov
ISPF
I have been asked if there is a utility that converts ISPF menus into XMENU/E format. Can anyone tell me if there is one available? I know of none. Regards, Richard Schuh
Re: ISPF/PDF CMS MACLIB - Maintenance
We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources. Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of A. Harry Williams Sent: Tuesday, August 18, 2009 7:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T compress the file COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. 3D= = 3D= ===
Re: ISPF/PDF CMS MACLIB - Maintenance
Any reason you can't change the LINK mode from MW to RR? As extra insurance delete the Write and Multi-write passwords from the MDISK. Less secure, but perhaps sufficient, would be changing the ACCESS command to access the disk as an extention of another disk, thus making it R/O. Even less elegant might be putting the MACLIB on a MDISK that is full so that it can't updated even though there is a write link to it. In any scenario you'd have to see what kind of error the appliation gets when it tries to update the MACLIB and your (and your users) tolerance fo r it. Brian Nielsen On Wed, 19 Aug 2009 11:28:46 -0700, Llewellyn, Mark mllew...@visa.com wrote: What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines.
Re: ISPF/PDF CMS MACLIB - Maintenance
On Wednesday, 08/19/2009 at 02:36 EDT, Llewellyn, Mark mllew...@visa.com wrote: We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources. Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. Warning: I know nothing about ISPF/PDF's Theory of Operation. Just perusing the ISPF/PDF manual, perhaps a LOCK of each member in the library would let you keep other people out whilst you replace the maclib? Given that each user has R/W access to the disk, control must be via an advisory lock manager. Once you have all the marbles, replace them with new marbles. Alan Altmark z/VM Development IBM Endicott
Re: ISPF/PDF CMS MACLIB - Maintenance
Back to first principles: 1) Can you replicate the *failure* so you'll know whether you've fixed it or made it worse? 2) It's important to understand how the guests detect updates. If it's via a handshake, can you simulate that? I like Harry's almost-atomic update via COPY then RENAME. It wouldn't be hard to write a small assembler program to check the timestamp and issue the ERASE/RENAME if it matches, to minimize the window (though clearly 3 lines of Rexx is pretty fast these days). So the question then becomes whether this is sufficient, and for that you need #2 above.
Re: ISPF/PDF CMS MACLIB - Maintenance
Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = == ===
Re: ISPF/PDF CMS MACLIB - Maintenance
On Tue, Aug 18, 2009 at 1:24 PM, Llewellyn, Markmllew...@visa.com wrote: Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. Hm. So the SVM that copies it off could tell if it has been updated in the meantime by checking timestamps, no? Could it also force a dummy update? I'm wondering if the problem is that users A, B, and C have a view of the disk, and then the file gets updated under them, and since it's done outside of ISPF, the normal (if MW can be called normal) ISPF You need to reACCESS notification doesn't happen. If instead: SVM copies off MACLIB, notes timestamp SVM compresses MACLIB SVM checks for changed timestamp If timestamp changed, go to step 1 Once it gets to THIS step, it causes an update It copies the MACLIB back (Or perhaps the last two steps should be reversed) Then the window of opportunity for mischief is only between the last two steps. And there could be more timestamp checking in there that would cause the whole thing to restart if needed (oy). At least we aren't designing something overly complex (!)
Re: ISPF/PDF CMS MACLIB - Maintenance
On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk. The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a read-only mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T compress the file COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = == ===
Re: ISPF/PDF CMS MACLIB - Maintenance
Advice that Chuckie would be proud of :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Stephen Frazier Sent: Friday, August 14, 2009 5:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Schuh, Richard wrote: The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months.. Don't worry about it breaking. If the old one dies then that is a great incentive for the developers to get the new one working quickly. :) I didn't say that. Who me. Never. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: ISPF/PDF CMS MACLIB - Maintenance
A straw at which I cannot grasp. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 6:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 7:20 PM, Schuh, Richardrsc...@visa.com wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Ah, true. Urgh. Got FlashCopy? Yes, I'm grasping at straw...
Re: ISPF/PDF CMS MACLIB - Maintenance
Unfortunately, that is not possible. This is a legacy application that is enterprise wide and the users have no knowledge that they are using it. It cannot be decommissioned until its replacement is fully operational sometime next month (assuming there are no delays). Management is fully aware of the problems with it and, like the people responsible for keeping it alive until then, hopes like hell that nothing major happens to either the application or its replacement in the interim. Fortunately, the main problems with the app can usually be fixed by restoring a backup and telling the users to redo what they have don since the restore point. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Friday, August 14, 2009 8:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Ok, then they've already Bet The Business, so it's not your problem. Les Schuh, Richard wrote: Unfortunately, that is not possible. This is a legacy application that is enterprise wide and the users have no knowledge that they are using it. It cannot be decommissioned until its replacement is fully operational sometime next month (assuming there are no delays). Management is fully aware of the problems with it and, like the people responsible for keeping it alive until then, hopes like hell that nothing major happens to either the application or its replacement in the interim. Fortunately, the main problems with the app can usually be fixed by restoring a backup and telling the users to redo what they have don since the restore point. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Friday, August 14, 2009 8:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind of VM service machine. If that's true, how about modifying the user code to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue a message to let the user know that it is temporarily unavailable, go int o a sleep loop and keep checking until the maintenance ID no longer has the MACLIB disk linked, then allow updates again, or terminate the user code with a message, etc. That might do the trick and wouldn't require a lot of work for a soon to be dead app, (we all know how dead things like to stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. - Kurt Vonnegut On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is ou r only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o n the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = ===
ISPF/PDF CMS MACLIB - Maintenance
Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application tha t makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activit y and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc.
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellynmllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Could the machine doing the compress LINK the disk eXclusive during the update?
Re: ISPF/PDF CMS MACLIB - Maintenance
Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 10:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellynmllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Could the machine doing the compress LINK the disk eXclusive during the update?
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
Access control is an ISPF function, I presume that one of the two locks (LMF or SCLM) is used to prevent concurrent updates of the same member. It must also have some way to serialize the updates of the library. That is an area that I have avoided. I hate working with kludges or black boxes. The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. ---Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Schuh, Richard wrote: The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months.. Don't worry about it breaking. If the old one dies then that is a great incentive for the developers to get the new one working quickly. :) I didn't say that. Who me. Never. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 7:20 PM, Schuh, Richardrsc...@visa.com wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Ah, true. Urgh. Got FlashCopy? Yes, I'm grasping at straw...
Re: ISPF/PDF CMS MACLIB - Maintenance
Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
ISPF Post-z/VM Installation
I need to install ISPF on my z/VM 5.4 system. I have recently installed RACF and need to add panel support. I have the electronic media from the Shop zSeries site as well as the DVD for the z/VM 5.4 SDO. How do I go about installing ISPF after the fact? Can I do it via FTP? Can that part be installed as a Product Envelope and if so, how do I go about getting it? Thanks, Dave
Re: ISPF Post-z/VM Installation
ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape.
Re: ISPF Post-z/VM Installation
Isn't it so old that the documentation is in Sanskrit? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape.
Re: ISPF Post-z/VM Installation
What I have is the z/VM 5.4 SDO media. If I need an additional ISPF product tape, I will need to order it. Thanks, Dave -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape.
Re: ISPF Post-z/VM Installation
Yes, if ISPF wasn't on your SDO tapes, you'll need to order it. You can get it on ShopZSeries and probably via internet delivery as a Program Product envelope. Or a real tape, but not a reel tape. On Tue, 5 May 2009 16:21:05 -0700, KEETON Dave * SDC dave.kee...@state.or.us wrote: What I have is the z/VM 5.4 SDO media. If I need an additional ISPF product tape, I will need to order it. Thanks, Dave -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape.
Re: ISPF Post-z/VM Installation
And comes on two stone tablets, delivered by the ghost of Charlton Heston . On Tue, 5 May 2009 16:19:24 -0700, Schuh, Richard rsc...@visa.com wrote : Isn't it so old that the documentation is in Sanskrit? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape. = ===
Re: ISPF Post-z/VM Installation
I don't have tapes - I have a DVD and I obtained the electronic version of the SDO from IBM this morning. I was hoping to get the Product Envelope, but I didn't see where I could get just that component. Dave -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation Yes, if ISPF wasn't on your SDO tapes, you'll need to order it. You can get it on ShopZSeries and probably via internet delivery as a Program Product envelope. Or a real tape, but not a reel tape. On Tue, 5 May 2009 16:21:05 -0700, KEETON Dave * SDC dave.kee...@state.or.us wrote: What I have is the z/VM 5.4 SDO media. If I need an additional ISPF product tape, I will need to order it. Thanks, Dave -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape.
Re: ISPF Post-z/VM Installation
Don't forget that if Dave is running his z/VM system on IFL engines and not CP ones, he'll need to license ISPF via the special bids process. I don't have a clue how one does that; contact your IBM or Business Partner for advice. Have a good one. C. Lawrence Perkins wrote: Yes, if ISPF wasn't on your SDO tapes, you'll need to order it. You can get it on ShopZSeries and probably via internet delivery as a Program Product envelope. Or a real tape, but not a reel tape. On Tue, 5 May 2009 16:21:05 -0700, KEETON Dave * SDC dave.kee...@state.or.us wrote: What I have is the z/VM 5.4 SDO media. If I need an additional ISPF product tape, I will need to order it. Thanks, Dave -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of C. Lawrence Perkins Sent: Tuesday, May 05, 2009 4:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF Post-z/VM Installation ISPF for VM is one of those semi-VMSES/E products. It's so old it predates the rigourous methodology of VMSES/E and had its own install method based on an install tool EXEC from earlier versions of VM. The z/VM 5.4 SDO Directory http://www.vm.ibm.com/sdo/sdozv54.pdf has a section on installing ISPF and describes the semi-VMSES/E procedure, Page 134. You'll also need the ISPF Program Directory, you can find it here: http://publibfi.boulder.ibm.com/epubs/pdf/i1114480.pdf This will help when you go to build the ISPF DCSS. And, I presume you have the ISPF product tape. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: ISPF install
I found the problem. I used the wrong VM definitions. I used the definitions for VM/XA instead of VM/SP. I sure would have thought since XA was newer than SP I should use that definition, but, no. OPTION DEVINFO is the key. On Tue, Jan 20, 2009 at 2:34 PM, Mark Pace mpac...@gmail.com wrote: I'm trying to install ISPF under z/VM 5.4 I've followed the directions in the SDO program directory. Loaded the code, built the Saved Segment. IPL the ISPVM service machine. I link to ISPVM 192 disk and run ISPSTART. I get an error - A severe error occurred when reading the profile table. Error Message: ISPT043 - VMSPF ERROR CODE X'0083' FROM VMSPF VIRTUAL MACHINE FOR FILE A1 The only place I can find this error message says ISPT043 VMSPF error - Code x'' from VMSPF virtual machine for file . Explanation: *This message is self explanatory.* Well, no it's not. I see that there is a blank for the file name, but I have no idea why or where I would change that. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
On Mon, 12 May 2008 01:07:04 -0500, Leland Lucius [EMAIL PROTECTED] wrote: It's not the best solution, but it does provide highlighting...just not in real time: http://vm.marist.edu/~pipeline/index.html#QDI And here's a mod I did to it for REXX keywords: http://homerow.net/zvm/qdi.htm Leland = I went to your link and clicked on qdi update but all I got was: Sorry homerow.net, you can't do qdi.update The same thing happened for updqdi exec. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
Quoting Alan Ackerman [EMAIL PROTECTED]: On Mon, 12 May 2008 01:07:04 -0500, Leland Lucius [EMAIL PROTECTED] wrote: It's not the best solution, but it does provide highlighting...just not in real time: http://vm.marist.edu/~pipeline/index.html#QDI And here's a mod I did to it for REXX keywords: http://homerow.net/zvm/qdi.htm Leland = I went to your link and clicked on qdi update but all I got was: Sorry homerow.net, you can't do qdi.update The same thing happened for updqdi exec. Sorry about that. I've let my site go a little and need to give it a little TLC one of these days. You can get the files from here: http://homerow.net/files/updqdi.exec http://homerow.net/files/qdi.update Leland
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
--On May 11, 2008 8:27:25 PM -0500 Lionel B. Dyck [EMAIL PROTECTED] wrote: Is it possible (and if so has anyone done it) to have an XEdit Macro that enables syntax highlighting similar to that available to the z/OS ISPF Ed itor? Hi Lionel, It's not the best solution, but it does provide highlighting...just not in real time: http://vm.marist.edu/~pipeline/index.html#QDI And here's a mod I did to it for REXX keywords: http://homerow.net/zvm/qdi.htm Leland
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
--On May 11, 2008 8:27:25 PM -0500 Lionel B. Dyck [EMAIL PROTECTED] wrote: Is it possible (and if so has anyone done it) to have an XEdit Macro that enables syntax highlighting similar to that available to the z/OS ISPF Ed itor? Hi Lionel, It's not the best solution, but it does provide highlighting...just not in real time: http://vm.marist.edu/~pipeline/index.html#QDI And here's a mod I did to it for REXX keywords: http://homerow.net/zvm/qdi.htm Leland
Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
Is it possible (and if so has anyone done it) to have an XEdit Macro that enables syntax highlighting similar to that available to the z/OS ISPF Ed itor? (No - I do not want to start a editor war) Thanks
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
On May 11, 2008, at 8:27 PM, Lionel B. Dyck wrote: Is it possible (and if so has anyone done it) to have an XEdit Macro that enables syntax highlighting similar to that available to the z/OS ISPF Ed itor? USE EMACS YOU HERETIC!!1!!one!1! (No - I do not want to start a editor war) Oh. Um, no idea. I *do* have a rexx-mode (and, saints preserve us, a COBOL-mode) for Emacs that does syntax coloring. But that probably doesn't help. Adam
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
There is LEXX... Not Xedit, but a WYSIWYG editor that does things like that. It's on the VM Downloads page and has parser packages for a variety of languages etc... Lee Lionel B. Dyck wrote: Is it possible (and if so has anyone done it) to have an XEdit Macro that enables syntax highlighting similar to that available to the z/OS ISPF Ed itor? (No - I do not want to start a editor war) Thanks -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
On Sun, 11 May 2008 20:27:25 -0500, Lionel B. Dyck [EMAIL PROTECTED] wrote: Is it possible (and if so has anyone done it) to have an XEdit Macro tha t enables syntax highlighting similar to that available to the z/OS ISPF E ditor? (No - I do not want to start a editor war) Thanks = === I use Kedit on my PC. It does support syntax checking. But of course it d oes not run on VM. I think I remember that LEXX does the job, but lacks some of the others capabilitie s of XEDIT. I haven't ever tried it though. The price is right! ($0.00. assuming your time is free.. .) Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Syntax Highlighting in XEdit (similar to z/OS ISPF Edit) ?
Alan Ackerman wrote: I use Kedit on my PC. Did anyone say X2? http://www.tangbu.com/x2main.shtml -- Jack J. Woehr# Hipsters believe that irony has http://www.well.com/~jax # more resonance than reason. http://www.softwoehr.com # - Robert Lanham
Display Menus without ISPF/VM ?
I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA
Re: Display Menus without ISPF/VM ?
there are a couple of good packages available (for free!) off of the VM download page at: http://www.vm.ibm.com/download/packages/ One is CUA2001 and another is ISO3270. Both are meant to be used from Rexx and offer a number of useful features and functions. Another good display manages is RDM/ESA available from the University of Victoria: http://uvvm.uvic.ca/~freeware/ FYI: Of the three, CUA2001 comes out of the box looking the most like ISPF. If you have people that are familiar with ISPF, it'll give you the quickest way to look and feel similar in terms of menus/pf keys, etc. Both the other packages require defining a lot of that behavior, if I remember correctly.
Re: Display Menus without ISPF/VM ?
We have used two different display/menu processors that are available fro m the IBM VM Downloads website. They are CUA2001 and IOS3270. CUA2001 is written in REXX and I believe uses XEDIT as its fundimental display engin e. IOS3270 is supplied only as executable modules ( xmod). This is muc h faster in terms of CPU resources and MY time for coding the menus and exe cs. /Tom Kern On Thu, 31 Jan 2008 11:44:02 -0600, Lionel B. Dyck [EMAIL PROTECTED] wrote: I don't have ISPF/VM and yet I would like to create simple display panel s with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility ? TIA = ===
Re: Display Menus without ISPF/VM ?
Lionel, there are a couple of good packages available (for free!) off of the VM download page at: http://www.vm.ibm.com/download/packages/ One is CUA2001 and another is ISO3270. Both are meant to be used from Rexx and offer a number of useful features and functions. Another good display manages is RDM/ESA available from the University of Victoria: http://uvvm.uvic.ca/~freeware/ Hope this helps. Lionel B. Dyck wrote: I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Display Menus without ISPF/VM ?
Another possibility from the VM download site is RXDISP. I haven't used because I was never an ISPF fan, but it's something to check out. Jim Huegel, Thomas wrote: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C86434.D05DFCBA Content-Type: text/plain; charset=iso-8859-1 It depends on what you mean by 'simple'. If your definition and mine are about the same, then use XEDIT. There are many examples around, look in the 'XEDIT COMMANDS and MACROS GUIDE' for help. Also there are some PIPE stages for fullscreen operations (I haven't used them). If your application is more sophisticated (less simple) then you should look at the other packages that have been suggested. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Lionel B. Dyck Sent: Thursday, January 31, 2008 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Display Menus without ISPF/VM ? I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Display Menus without ISPF/VM ?
It depends on what you mean by 'simple'. If your definition and mine are about the same, then use XEDIT. There are many examples around, look in the 'XEDIT COMMANDS and MACROS GUIDE' for help. Also there are some PIPE stages for fullscreen operations (I haven't used them). If your application is more sophisticated (less simple) then you should look at the other packages that have been suggested. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Lionel B. Dyck Sent: Thursday, January 31, 2008 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Display Menus without ISPF/VM ? I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA
Re: Display Menus without ISPF/VM ?
This is a simple XEDIT: /* REXX */ 'xedit xpanel data a (prof xpanel'=== The name of your Xedit Profile say 'Your results are:' 'EXECIO * DISKR XPANEL DATA A2 1 (STEM VMFA.' 'EXECIO 0 DISKR XPANEL DATA A2 (FINIS' vmfa = VMFA.0 do x = 1 to vmfa parse var vmfa.x . 'Input:' data data = strip(data) say 'Record' x 'DATA:' data end exit 0 /* Xedit Profile */ /* */ dt = Date(u) tm = Time() strng = dt || ' Data Entry Panel ' || tm hdr0 = ' ' 'set ctlchar ! escape' 'set ctlchar % noprotect green underline' 'set ctlchar protect nohigh' 'set reserved 1 yellow rev high ' strng 'set reserved 2 turq nohigh' hdr0 field1 = 'field 1' field2 = 'field 2' 'set reserved 3 turq rev high Enter Field 1:' 'set reserved 4 noh One:!% !' 'set reserved 5 turq rev high Enter Field 2:' 'set reserved 6 noh Two:!% !' 'set reserved 7 Default None Nohigh' 'set reserved 8 Default None Nohigh' 'set reserved 9 Default None Nohigh' 'set reserved 10 Default None Nohigh' 'set reserved 11 Default None Nohigh' 'set reserved 12 Default None Nohigh' 'set reserved 13 Default None Nohigh' 'set reserved 14 Default None Nohigh' 'set reserved 15 Default None Nohigh' 'set reserved 16 Default None Nohigh' 'set reserved 17 Default None Nohigh' 'set reserved 18 Default None Nohigh' 'set reserved 19 Default None Nohigh' 'set reserved 20 Default None Nohigh' 'set reserved 21 Default None Nohigh' 'set reserved 22 Default None Nohigh' 'command cursor screen 4 6' 'READ All Tag' VMFA = queued() Do x = 1 to VMFA Parse upper pull V1 V2 V3 V4 . Select When x = 1 then do 'ERASE XPANEL DATA A2' 'EXECIO 0 DISKW XPANEL DATA A2 0 F 80' end When x = 2 then do if V2 = 4 then do out = 'Field 1 Input: ' V4 'EXECIO 1 DISKW XPANEL DATA A2 1 ( STRING' OUT end if V2 = 6 then do out = 'Field 2 Input: ' V4 'EXECIO 1 DISKW XPANEL DATA A2 2 ( STRING' OUT end end When x = 3 then do if V2 = 6 then do out = 'Field 2 Input: ' V4 'EXECIO 1 DISKW XPANEL DATA A2 2 ( STRING' OUT end end Otherwise nop /* select */ End 'FINIS XPANEL DATA A2' /* do */ End /* */ 'Quit' HTH - Dave H. Lionel B. Dyck [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc 01/31/2008 11:44 AM Subject Display Menus without ISPF/VM ? Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU I don't have ISPF/VM and yet I
Re: Display Menus without ISPF/VM ?
Lionel ... As several have mentioned, there are packages which will help. But also: You can do a lot of full-screen 3270 work using XEDIT. Many VMers have done amazing things using only XEDIT. But there would be a learning curve. If I can find contact info for my BMC colleague Larry Dinwiddie, he could give you some tips to shorten the curve. (And he may be monitoring this list. Larry?) On Jan 31, 2008 12:44 PM, Lionel B. Dyck [EMAIL PROTECTED] wrote: I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA -- -- R;
Re: Display Menus without ISPF/VM ?
Lionel, I did a fair amount of pure-XEDIT panel design back in the Y2K days, both by hand (it's not hard) and writing Rexx apps to dynamically generate and use them. Let's try to carve out some time next week to talk about it. -Chip- On 1/31/08 17:44 Lionel B. Dyck said: I don't have ISPF/VM and yet I would like to create simple display panels with menus and data entry options. Is there a way to do this using XEdit or some other native z/VM facility? TIA
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
Hi, I moved an ISPF rexx application I wrote from VM to MVS. It's a manual migration. REXX is what I used to drive to panels. On VM I could pre-process the panels. As far as what's in a panel, (all the definitions), some due point to the source of the panel or the EXEC by PFKey. So your flow will have to be modified to reference MVS datasets. I had some trouble with the colors, but this was many years ago. The reason I don't run much ISPF under VM any more is PROFS went away and so did ISPF for a lot of VM shoppes. Hope that helps, Dave Hansen Sr. Systems Programmer Hennepin County Raymond Noal [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc 01/03/2008 02:53 PM Subject z/OS + TSO + ISPF versus z/VM + CMS + ISPF Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Dear Lists: I am cross posting this question to the z/OS and z/VM lists due to the nature of my question, which is – Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/conversion effort involved in going from one to the other? (primarily from the TSO to CMS based ISPF platform) I thank you in advance for your time and assistance. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
On Thursday, 01/03/2008 at 03:56 EST, Raymond Noal [EMAIL PROTECTED] wrote: Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/conversion effort involved in going from one to the other? (primarily from the TSO to CMS based ISPF platform) I thank you in advance for your time and assistance. I believe they will work, but recognize that ISPF on z/VM, unlike on z/OS, costs extra. If you have IFLs, a Special Bid is required. Alan Altmark z/VM Development IBM Endicott
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
Hi, Raymond. I believe the answer is yes, but. Yes, you can port a z/OS-TSO-ISPF panel application over to z/VM-CMS-ISPF, but you will need to modify all the file access and i/o from TSO specific to CMS specific, remove any advanced ISPF panel features that you might have used in the TSO version (the version of ISPF for z/VM is very outdated now and lacks some of the newer features introduced over the last 10 or so years for z/OS ISPF), you'll also have to convert from z/OS PDS filesthat contain the ISPF panels, messages, etc. to either CMS maclibs or flat files. Yes, simple ISPF applications can be ported without a great deal of effort, but more complex ones, that have a great deal of interaction between panels might not be. Raymond Noal wrote: Dear Lists: I am cross posting this question to the z/OS and z/VM lists due to the nature of my question, which is - Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/conversion effort involved in going from one to the other? (primarily from the TSO to CMS based ISPF platform) I thank you in advance for your time and assistance. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
This won't help Raymond any, but it reminded me of something. I used to write a lot of panel apps using a VM program product called Display Management System for CMS. It had interfaces for EXEC/EXEC2, COBOL, PL/I, RPG, and BAL, but I used REXX with no problems. Admittedly it was ISPF-Lite but it did everything we needed for some pretty sophisticated applications. It has a slick (well, for 1980) interactive panel design tool that would let you build anything a 327x could display. DMS was really lightweight and fast, both in time-to-production and execution speed. Anyone know what happened to it? -Chip Davis- Aresti Systems, LLC On 1/3/08 21:18 Alan Altmark said: On Thursday, 01/03/2008 at 03:56 EST, Raymond Noal [EMAIL PROTECTED] wrote: Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/conversion effort involved in going from one to the other? (primarily from the TSO to CMS based ISPF platform) I thank you in advance for your time and assistance. I believe they will work, but recognize that ISPF on z/VM, unlike on z/OS, costs extra. If you have IFLs, a Special Bid is required. Alan Altmark z/VM Development IBM Endicott
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
On Thursday, 01/03/2008 at 04:59 EST, Chip Davis [EMAIL PROTECTED] wrote: This won't help Raymond any, but it reminded me of something. I used to write a lot of panel apps using a VM program product called Display Management System for CMS. It had interfaces for EXEC/EXEC2, COBOL, PL/I, RPG, and BAL, but I used REXX with no problems. Admittedly it was ISPF-Lite but it did everything we needed for some pretty sophisticated applications. It has a slick (well, for 1980) interactive panel design tool that would let you build anything a 327x could display. DMS was really lightweight and fast, both in time-to-production and execution speed. Anyone know what happened to it? Display Management System/CMS (DMS/CMS) Version 2, 5684-113, (ca. 1989) is still available. You can also order it separately or with the z/VM SDO. You need a Special Bid to get it on IFLs. Alan Altmark z/VM Development IBM Endicott
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
Hi, Chip. As Alan has already informed us, DMS/CMS is still available for z/VM. Another tool that can support DMS/CMS applications with no change to either the programs, panels, or PCB files is RDM/ESA from the University of Victoria. IBM also had at one time an IUO program called NEATWIND, written by Brendan Jones, IBM A/NZ. It was quite impressive with what it could do to manipulate and display 3270 screens. Chip Davis wrote: This won't help Raymond any, but it reminded me of something. I used to write a lot of panel apps using a VM program product called Display Management System for CMS. It had interfaces for EXEC/EXEC2, COBOL, PL/I, RPG, and BAL, but I used REXX with no problems. Admittedly it was ISPF-Lite but it did everything we needed for some pretty sophisticated applications. It has a slick (well, for 1980) interactive panel design tool that would let you build anything a 327x could display. DMS was really lightweight and fast, both in time-to-production and execution speed. Anyone know what happened to it? -Chip Davis- Aresti Systems, LLC On 1/3/08 21:18 Alan Altmark said: On Thursday, 01/03/2008 at 03:56 EST, Raymond Noal [EMAIL PROTECTED] wrote: Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/conversion effort involved in going from one to the other? (primarily from the TSO to CMS based ISPF platform) I thank you in advance for your time and assistance. I believe they will work, but recognize that ISPF on z/VM, unlike on z/OS, costs extra. If you have IFLs, a Special Bid is required. Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF
As Alan has already informed us, DMS/CMS is still available for z/VM. Another tool that can support DMS/CMS applications with no change to either the programs, panels, or PCB files is RDM/ESA from the University of Victoria. IBM also had at one time an IUO program called NEATWIND, written by Brendan Jones, IBM A/NZ. It was quite impressive with what it could do to manipulate and display 3270 screens. Don't forget IOS3270 and CUA2001 if you're going to rework the apps. All of the above display managers provide nice features, but none are directly compatible with ISPF. -- db
Re: freeware ISPF panel like utility for RACF for VM?
I've got a wonderfull RACFULL package that I enhanced a bit. I've got the permission of Trevor B. Russell (the original IBM author) to distribute it. I was planning to put this too on the VM download lib some day after some extra polishing, but same day has not arrived yet. It has no prereqs, used CMS WINDOW/VSCREEN commands to make its panels. You simply overtype fields to change settings. A new thing I added -and that you won't understand without this explanation- is that you can have the RACF commands be shipped to a server, named OPCUSER. This OPCUSER server is RACF SPECIAL, something our personal userID is not. But, we -VM sysprogs- may issue these commands through OPCUSER as the OPCUSER server will log them all. This feature is visible on the primary panel as an extra line Issue RACF commands using OPCUSER ? Yes (Yes or No) when a userid OPCUSER is logged on. Change RACFULL EXEC if not appropriate. We use it daily. Available on request. 2007/5/18, David Boyes [EMAIL PROTECTED]: Thanks all , esp. David for your help! RLPF looks good to me, just hope it will work with z/VM v5.2 too. It should, if all the ISPF bits still work properly. RLPF is more dependent on RACF version than on VM version. ISPF/VM hasn't changed in a zillion years (at least 10, anyway), but I don't think there's anything there that will cause you problems. -- Kris Buelens, IBM Belgium, VM customer support
freeware ISPF panel like utility for RACF for VM?
Hi, I was wondering if anyone know of some freeware utility that will provide z/OS ISPF panel like view for RACF with z/VM. My customer would love to have some kind of an interface instead of just command lines when using RACF for VM. Thanks for your help in advance! Cara Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca
Re: freeware ISPF panel like utility for RACF for VM?
Let us not forget XEDIT macroes. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Munson Sent: Friday, May 18, 2007 2:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: freeware ISPF panel like utility for RACF for VM? Cara, What is wrong with the VM ISPF product. When I was mainting RACF (1.10) on VM about 15 years ago I used the VM ISPF Panels just like the MVS guys did. alas that was a long time ago during the good ole days ;) Bill Munson IT Specialist VM System Programmer Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Cara Li wrote: Hi, I was wondering if anyone know of some freeware utility that will provide z/OS ISPF panel like view for RACF with z/VM. My customer would love to have some kind of an interface instead of just command lines when using RACF for VM. Thanks for your help in advance! Cara -- -- Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the *All-new Yahoo! Mail * http://us.rd.yahoo.com/evt=40705/*http://mrd.mail.yahoo.com/try_beta?.i ntl=ca If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: freeware ISPF panel like utility for RACF for VM?
Cara, What is wrong with the VM ISPF product. When I was mainting RACF (1.10) on VM about 15 years ago I used the VM ISPF Panels just like the MVS guys did. alas that was a long time ago during the good ole days ;) Bill Munson IT Specialist VM System Programmer Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Cara Li wrote: Hi, I was wondering if anyone know of some freeware utility that will provide z/OS ISPF panel like view for RACF with z/VM. My customer would love to have some kind of an interface instead of just command lines when using RACF for VM. Thanks for your help in advance! Cara Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the *All-new Yahoo! Mail * http://us.rd.yahoo.com/evt=40705/*http://mrd.mail.yahoo.com/try_beta?.intl=ca
Re: freeware ISPF panel like utility for RACF for VM?
Wouldn't we all, although I'd rather avoid ISPF in favor of something more VM friendly like CUA2001 or IOS3270. Make sure they are using the RACF integration with DIRMAINT, which helps somewhat. Also check out RLPF from the VM download library (http://www.vm.ibm.com/download/packages/descript.cgi?RLPF) to see if that meets your needs. I was wondering if anyone know of some freeware utility that will provide z/OS ISPF panel like view for RACF with z/VM. My customer would love to have some kind of an interface instead of just command lines when using RACF for VM. Thanks for your help in advance!
Re: freeware ISPF panel like utility for RACF for VM?
cool ;) David Boyes wrote: What is wrong with the VM ISPF product. It's next to impossible to license it on IFLs, and it's very expensive for just the task of displaying simple. It's also a non-trivial install if you have few CMS skills.
Re: freeware ISPF panel like utility for RACF for VM?
What is wrong with the VM ISPF product. It's next to impossible to license it on IFLs, and it's very expensive for just the task of displaying simple. It's also a non-trivial install if you have few CMS skills.
Re: freeware ISPF panel like utility for RACF for VM?
Thanks all , esp. David for your help! RLPF looks good to me, just hope it will work with z/VM v5.2 too. Have a great weekend! Cara - Original Message From: Bill Munson [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Sent: Friday, May 18, 2007 2:36:12 PM Subject: Re: freeware ISPF panel like utility for RACF for VM? cool ;) David Boyes wrote: What is wrong with the VM ISPF product. It's next to impossible to license it on IFLs, and it's very expensive for just the task of displaying simple. It's also a non-trivial install if you have few CMS skills. Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca
Re: freeware ISPF panel like utility for RACF for VM?
Thanks all , esp. David for your help! RLPF looks good to me, just hope it will work with z/VM v5.2 too. It should, if all the ISPF bits still work properly. RLPF is more dependent on RACF version than on VM version. ISPF/VM hasn't changed in a zillion years (at least 10, anyway), but I don't think there's anything there that will cause you problems.
ISPF File Tailoring
OK, here is an example of some file tailoring that we do for our programming staff using ISPF and Dialog Manager. This one creates a compile job stream for a COBOL CICS program. It may or may not contain SQL statements, that is determined by the library type (COBOL or SQLCOBOL). A REXX EXEC drives the process (display panel, do some basic editing to validate what can't be handled on the panel itself, invoke file tailoring to create top of JCL, punch it, punch source member, file tailoring for bottom of JCL, punch it). It uses ISPF shared and profile variables to initially populate the panel (but I would guess that CMS global variables would work just fine too). I could handle the XEDIT full screen stuff to replace the panel, but I don't know much about CMS plumbing if that's what would replace file tailoring. Sorry for the length of this post, but the skeletons are pretty big! I appreciate any thoughts on how to convert something like this. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 Here is the panel: -- IMCO Compile Options - COMMAND === ISPF Library:Compiler === NEW Project === TECH Group === EDC COBOL CICS Type=== COBOL Member === Phase Name === ( required ) Output Lib === TESTLIB.ED ( VSE output library ) Search Lib === TESTLIB.ED ( VSE search library ) SQL User ID === IMCO( Owner of the SQL program ) SQL Link Edit? === N ( Y or N ) DOS User Info === EZ ( DOS USER information ) Print Disp === D ( D H K L ) Print Class === T DEST === ED( A - Z Class=T goes to VM ) SQL Grant Run? === N ( Y or N ) SQL Isolation === CS ( CS or RR ) CICS Immediate? === N ( Y or N ) Here is the top ISPF skeleton for a non-SQL COBOL program: * $$ JOB JNM=COMPPHAS,CLASS=RDRCLASS,DISP=RDRDISP,PRI=RDRPRI,USER=RDRUSER * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX * $$ PUN DISP=I,CLASS=RDRCLASS,PRI=RDRPRI // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K )SEL CICSIMM = Y // EXEC PGM=LIBR ACCESS S=DELCATLG DELETE COMPPHAS..PHASE /* )ENDSEL )SEL SQLPREP = Y ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX * $$ PUN DISP=I,CLASS=RDRCLASS,PRI=RDRPRI // JOB COMPPHAS DOSUSER ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF OBJ,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF PHASE,CATALOG=WRKCATLG )SEL COMPILER = OLD // OPTION CATAL,LIST,LISTX )ENDSEL )SEL COMPILER = NEW // OPTION CATAL )ENDSEL PHASE COMPPHAS,* INCLUDE DFHECI INCLUDE ARIRRTED )SEL COMPILER = OLD // EXEC PGM=FCOBOL,SIZE=512K CBL NOSEQ,SUPMAP,CLIST,SXREF,LIB,VERB,APOST,NOADV,LANGLVL(1) )ENDSEL )SEL COMPILER = NEW // EXEC PGM=IGYCRCTL,SIZE=IGYCRCTL )ENDSEL END /* // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP )SEL COMPILER = NEW // UPSI 010 )ENDSEL // OPTION DECK // EXEC DFHECP1$,SIZE=512K )SEL COMPILER = OLD CBL XOPTS( CICS DEBUG LANGLVL(1)) )ENDSEL )SEL COMPILER = NEW CBL XOPTS( ANSI85 CICS DEBUG ) )ENDSEL END /* // ASSGN SYSPCH,02D // OPTION DECK // EXEC PGM=SQLPRPC,SIZE=AUTO,PARM='SQLPARM1 SQLPARM2' )ENDSEL )SEL SQLPREP = N ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF OBJ,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF PHASE,CATALOG=WRKCATLG )SEL COMPILER = OLD // OPTION CATAL,LIST,LISTX )ENDSEL )SEL COMPILER = NEW // OPTION CATAL )ENDSEL PHASE COMPPHAS,* INCLUDE DFHECI )SEL SQLLINK = Y INCLUDE ARIRRTED )ENDSEL )SEL COMPILER = OLD // EXEC PGM=FCOBOL,SIZE=512K CBL NOSEQ,SUPMAP,CLIST,SXREF,LIB,VERB,APOST,NOADV,LANGLVL(1) )ENDSEL )SEL COMPILER = NEW // EXEC PGM=IGYCRCTL,SIZE=IGYCRCTL )ENDSEL END /* )SEL COMPILER = NEW // UPSI 010 )ENDSEL // OPTION DECK // EXEC DFHECP1$,SIZE=512K )SEL COMPILER = OLD CBL XOPTS( CICS DEBUG LANGLVL(1)) )ENDSEL )SEL COMPILER = NEW CBL XOPTS( ANSI85 CICS DEBUG ) )ENDSEL )ENDSEL Here is the bottom ISPF skeleton for a non-SQL COBOL program: /* )SEL SQLPREP = Y ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K /* ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K /* )SEL COMPILER = NEW // IF $RC GE 8 THEN // GOTO $EOJ )ENDSEL
Re: ISPF File Tailoring
It's not so much a plumbing exercise as it is changing the JCL skeleton to use REXX variables and REXX style logic. No global variables required, unless your passing data between invocations of the EXEC. Ed Zell wrote: OK, here is an example of some file tailoring that we do for our programming staff using ISPF and Dialog Manager. This one creates a compile job stream for a COBOL CICS program. It may or may not contain SQL statements, that is determined by the library type (COBOL or SQLCOBOL). A REXX EXEC drives the process (display panel, do some basic editing to validate what can't be handled on the panel itself, invoke file tailoring to create top of JCL, punch it, punch source member, file tailoring for bottom of JCL, punch it). It uses ISPF shared and profile variables to initially populate the panel (but I would guess that CMS global variables would work just fine too). I could handle the XEDIT full screen stuff to replace the panel, but I don't know much about CMS plumbing if that's what would replace file tailoring. Sorry for the length of this post, but the skeletons are pretty big! I appreciate any thoughts on how to convert something like this. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 Here is the panel: -- IMCO Compile Options - COMMAND === ISPF Library:Compiler === NEW Project === TECH Group === EDC COBOL CICS Type=== COBOL Member === Phase Name === ( required ) Output Lib === TESTLIB.ED ( VSE output library ) Search Lib === TESTLIB.ED ( VSE search library ) SQL User ID === IMCO( Owner of the SQL program ) SQL Link Edit? === N ( Y or N ) DOS User Info === EZ ( DOS USER information ) Print Disp === D ( D H K L ) Print Class === T DEST === ED( A - Z Class=T goes to VM ) SQL Grant Run? === N ( Y or N ) SQL Isolation === CS ( CS or RR ) CICS Immediate? === N ( Y or N ) Here is the top ISPF skeleton for a non-SQL COBOL program: * $$ JOB JNM=COMPPHAS,CLASS=RDRCLASS,DISP=RDRDISP,PRI=RDRPRI,USER=RDRUSER * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX * $$ PUN DISP=I,CLASS=RDRCLASS,PRI=RDRPRI // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K )SEL CICSIMM = Y // EXEC PGM=LIBR ACCESS S=DELCATLG DELETE COMPPHAS..PHASE /* )ENDSEL )SEL SQLPREP = Y ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX * $$ PUN DISP=I,CLASS=RDRCLASS,PRI=RDRPRI // JOB COMPPHAS DOSUSER ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF OBJ,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF PHASE,CATALOG=WRKCATLG )SEL COMPILER = OLD // OPTION CATAL,LIST,LISTX )ENDSEL )SEL COMPILER = NEW // OPTION CATAL )ENDSEL PHASE COMPPHAS,* INCLUDE DFHECI INCLUDE ARIRRTED )SEL COMPILER = OLD // EXEC PGM=FCOBOL,SIZE=512K CBL NOSEQ,SUPMAP,CLIST,SXREF,LIB,VERB,APOST,NOADV,LANGLVL(1) )ENDSEL )SEL COMPILER = NEW // EXEC PGM=IGYCRCTL,SIZE=IGYCRCTL )ENDSEL END /* // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP )SEL COMPILER = NEW // UPSI 010 )ENDSEL // OPTION DECK // EXEC DFHECP1$,SIZE=512K )SEL COMPILER = OLD CBL XOPTS( CICS DEBUG LANGLVL(1)) )ENDSEL )SEL COMPILER = NEW CBL XOPTS( ANSI85 CICS DEBUG ) )ENDSEL END /* // ASSGN SYSPCH,02D // OPTION DECK // EXEC PGM=SQLPRPC,SIZE=AUTO,PARM='SQLPARM1 SQLPARM2' )ENDSEL )SEL SQLPREP = N ASSGN SYS006,02D // EXEC PGM=EDP001,SIZE=128K * $$ LST SYSID=N,DISP=PRTDISP,CLASS=PRTCLASSPRTDESTX // JOB COMPPHAS DOSUSER // EXEC PGM=PRINTJOB,SIZE=128K // LIBDEF SOURCE,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF OBJ,SEARCH=(LIBSRCH,LIBRARY.UL,LIBRARY.PROD),TEMP // LIBDEF PHASE,CATALOG=WRKCATLG )SEL COMPILER = OLD // OPTION CATAL,LIST,LISTX )ENDSEL )SEL COMPILER = NEW // OPTION CATAL )ENDSEL PHASE COMPPHAS,* INCLUDE DFHECI )SEL SQLLINK = Y INCLUDE ARIRRTED )ENDSEL )SEL COMPILER = OLD // EXEC PGM=FCOBOL,SIZE=512K CBL NOSEQ,SUPMAP,CLIST,SXREF,LIB,VERB,APOST,NOADV,LANGLVL(1) )ENDSEL )SEL COMPILER = NEW // EXEC PGM=IGYCRCTL,SIZE=IGYCRCTL )ENDSEL END /* )SEL COMPILER = NEW // UPSI 010 )ENDSEL // OPTION DECK // EXEC DFHECP1$,SIZE=512K )SEL COMPILER = OLD CBL XOPTS( CICS DEBUG LANGLVL(1)) )ENDSEL )SEL COMPILER = NEW CBL XOPTS( ANSI85 CICS DEBUG ) )ENDSEL )ENDSEL Here is the bottom ISPF
Re: ISPF File Tailoring
I think the globalv variables would be information that is the same from one invocation to the next, such as userid, jobclass, destination, account numbers, etc. A typical skeleton jcl modifying pipeline would be something like this: 'PIPE ' skel_fn skel_ft skel_fm , '| change /USER/'|| userid() ||'/' , '| change /DEST/'|| destination ||'/' , '| change /J/'|| jdate ||'/' , ' OUTPUT JCL A' Then you submit the OUTPUT JCL file to your batch system. I think the SUB MIT program I use came from the IBM DOWNLOADs website. On Thu, 18 Jan 2007 07:33:18 -0600, Rich Smrcina [EMAIL PROTECTED] wro te: It's not so much a plumbing exercise as it is changing the JCL skeleton to use REXX variables and REXX style logic. No global variables required, unless your passing data between invocations of the EXEC. Ed Zell wrote: OK, here is an example of some file tailoring that we do for our programming staff using ISPF and Dialog Manager. This one creates a compile job stream for a COBOL CICS program. It may or may not contain SQL statements, that is determined by the library type (COBOL or SQLCOBOL). A REXX EXEC drives the process (display panel, do some basic editing to validate what can't be handled on the panel itself, invoke file tailoring to create top of JCL, punch it, punch source member, file tailoring for bottom of JCL, punch it). It uses ISPF shared and profile variables to initially populate the panel (but I would guess that CMS global variables would work just fine too). I could handle the XEDIT full screen stuff to replace the panel, but I don't know much about CMS plumbing if that's what would replace file tailoring. Sorry for the length of this post, but the skeletons are pretty big! I appreciate any thoughts on how to convert something like this.
Re: ISPF File Tailoring
On Thu, 18 Jan 2007 07:26:30 -0600, Ed Zell [EMAIL PROTECTED] w rote: OK, here is an example of some file tailoring that we do for our programming staff using ISPF and Dialog Manager. This one creates a compile job stream for a COBOL CICS program. It may or may not contain SQL statements, that is determined by the library type (COBOL or SQLCOBOL). A REXX EXEC drives the process (display panel, do some basic editing to validate what can't be handled on the panel itself, invoke file tailoring to create top of JCL, punch it, punch source member, file tailoring for bottom of JCL, punch it). It uses ISPF shared and profile variables to initially populate the panel (but I would guess that CMS global variables would work just fine too). I could handle the XEDIT full screen stuff to replace the panel, but I don't know much about CMS plumbing if that's what would replace file tailoring. Sorry for the length of this post, but the skeletons are pretty big! I appreciate any thoughts on how to convert something like this. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 At the risk of losing my VM Bigot button, I'll have to say that customizi ng JCL is exactly what ISPF is good at. The actual customizing of a skeleton is easily done with XEDI T or Pipelines or REXX. But ISPF puts up a nice simple form to fill, in, remembers what you enter for next time, and then uses those values to create the JCL. All that is quite easy to set up -- a pie ce of cake. You can of course use XEDIT or CUA2001 or DMS/CMS or XMENU or ..., to put up the screen, then save the values with the GLOBALV command, then write a simple Pipeline to customize the skeleton JCL. I could probably (still) do it quicker in ISPF. 25+ years ago I wrote code to customize and submit JCL. I used the tools available at the time: EDIT and EXEC(1). Just stack a bunch of CHANGE commands and then call EDI T against the file. It didn't have a front-end form though, just positional parameters for the E XEC call.
ISPF and ISPF/PDF
Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
We still have several applications that use ISPDF/PDF. There is a project to convert and enhance the most critical of them. After that, we will try to ferret out any other uses and correct them. There is no new development that will use ISPF/PDF. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Tuesday, January 16, 2007 9:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: ISPF and ISPF/PDF Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
We still use it. Not for anything new, mind you. But spending the money to convert unsupported applications from ISPF to something else would likely be more expensive in the long run. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Ed Zell [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/16/2007 11:45 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject ISPF and ISPF/PDF Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: ISPF and ISPF/PDF
We still have it... for another vendors file transfer app. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Tuesday, January 16, 2007 10:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] ISPF and ISPF/PDF We still have several applications that use ISPDF/PDF. There is a project to convert and enhance the most critical of them. After that, we will try to ferret out any other uses and correct them. There is no new development that will use ISPF/PDF. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Tuesday, January 16, 2007 9:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: ISPF and ISPF/PDF Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
Ed, We still have it. Dennis O'Brien Are you on the list? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Tuesday, January 16, 2007 09:45 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] ISPF and ISPF/PDF Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
Us too. Also, the ISPF portion is used by DFSMS. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Tuesday, January 16, 2007 1:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF and ISPF/PDF We still have it... for another vendors file transfer app. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Tuesday, January 16, 2007 10:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] ISPF and ISPF/PDF We still have several applications that use ISPDF/PDF. There is a project to convert and enhance the most critical of them. After that, we will try to ferret out any other uses and correct them. There is no new development that will use ISPF/PDF. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: Tuesday, January 16, 2007 9:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: ISPF and ISPF/PDF Speaking of software that hasn't changed much in the last 10 years We still run ISPF and ISPF/PDF. The last fixes I put on were Y2K related back in 1997 or 1998 IIRC. Is anyone else still using these products? Since they are so stable and no new work is being done on them, should I still be paying as much to license them? What scares me is that the price will jump significantly if we decide to move to a new z-box. And we will still be doing the exact same thing with them that we do today. None of the new cycles/MIPS will have anything to do with the products. Is there any validity to my thoughts or should I just accept that the software pricing is what it is and deal with it? I would appreciate any comments. Thanks. Ed Zell Illinois Mutual Life Insurance (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: ISPF and ISPF/PDF
We still have it. Are you on the list? Dennis, No, I wasn't aware of a list for ISPF/PDF. Can you please send me the particulars? Thanks. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
At 02:53 PM 1/16/2007, you wrote: We still have it. Are you on the list? Dennis, No, I wasn't aware of a list for ISPF/PDF. Can you please send me the particulars? Thanks. [EMAIL PROTECTED]
Re: ISPF and ISPF/PDF
We still use it. Not for anything new, mind you. But spending the money to convert unsupported applications from ISPF to something else would likely be more expensive in the long run. And IBM probably knows that, so there is no motivation for them to lower the cost for us long time VM shops. Now I wish I hadn't created so many cool utilities for the programming staff over the years using Dialog Manager :( Isn't that a sad way of thinking I guess the other thing I could do is call in all on the minor issues that we have lived with over the years and insist on getting fixes. Then I could feel like I am getting my money's worth for the maintenance fees. But that just goes against my nature and would be so counter productive for both Illinois Mutual and IBM. Anyway, I've vented a bit and feel a little better. No comments on the fact that I don't look any better though :) Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
Who knows. The list is not very active. I am sure there are a few vm sites on the list. duane At 03:06 PM 1/16/2007, you wrote: [EMAIL PROTECTED] Duane, Thanks. Is it pretty much a z/OS ISPF list or do they speak VM? Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. Ed Zell wrote: We still use it. Not for anything new, mind you. But spending the money to convert unsupported applications from ISPF to something else would likely be more expensive in the long run. And IBM probably knows that, so there is no motivation for them to lower the cost for us long time VM shops. Now I wish I hadn't created so many cool utilities for the programming staff over the years using Dialog Manager :( Isn't that a sad way of thinking I guess the other thing I could do is call in all on the minor issues that we have lived with over the years and insist on getting fixes. Then I could feel like I am getting my money's worth for the maintenance fees. But that just goes against my nature and would be so counter productive for both Illinois Mutual and IBM. Anyway, I've vented a bit and feel a little better. No comments on the fact that I don't look any better though :) Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: ISPF and ISPF/PDF
Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. I have done that with a few apps, but we generate a ton of VSE JCL using ISPF file tailoring. I've never really found a way to get away from it that is as simple and easy as file tailoring. Any thoughts there? Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: ISPF and ISPF/PDF
We still have it... for another vendors file transfer app. We dumped NDM years ago, and then ISPF (/DM part only). Shimon
Re: ISPF and ISPF/PDF
Ed, If you can share these utilities, some of us might be interested in one or two and be willing to pick up the burden of rewritting your ISPF/DM utility in REXX/Pipelines/Xedit and then return the new version to you. /Tom Kern /301-903-2211 --- Rich Smrcina [EMAIL PROTECTED] wrote: Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. Ed Zell wrote: We still use it. Not for anything new, mind you. But spending the money to convert unsupported applications from ISPF to something else would likely be more expensive in the long run. And IBM probably knows that, so there is no motivation for them to lower the cost for us long time VM shops. Now I wish I hadn't created so many cool utilities for the programming staff over the years using Dialog Manager :( Isn't that a sad way of thinking ...snipped... Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail
Re: ISPF and ISPF/PDF
I've never used ISPF, so I'm not sure what 'ISPF file tailoring' is, but if it's something like entering parameters or values of some sort, I expect it could be duplicated to a certain extent. Ed Zell wrote: Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. I have done that with a few apps, but we generate a ton of VSE JCL using ISPF file tailoring. I've never really found a way to get away from it that is as simple and easy as file tailoring. Any thoughts there? Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: ISPF and ISPF/PDF
'ISPF file tailoring' is used for JCL generation in MVS - a 'skeleton' JCL file is read, variable substitution takes place and then written out. This is obviously a gross simplification of what it's used for. Mark Gillis Senior Software Engineer Tel: +61 2 9429 2337 Fax: +61 2 9429 2394 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Wednesday, 17 January 2007 12:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF and ISPF/PDF I've never used ISPF, so I'm not sure what 'ISPF file tailoring' is, but if it's something like entering parameters or values of some sort, I expect it could be duplicated to a certain extent. Ed Zell wrote: Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. I have done that with a few apps, but we generate a ton of VSE JCL using ISPF file tailoring. I've never really found a way to get away from it that is as simple and easy as file tailoring. Any thoughts there? Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: ISPF and ISPF/PDF
Thanks for the info, sounds sort of like what I thought. Gillis, Mark wrote: 'ISPF file tailoring' is used for JCL generation in MVS - a 'skeleton' JCL file is read, variable substitution takes place and then written out. This is obviously a gross simplification of what it's used for. Mark Gillis Senior Software Engineer Tel: +61 2 9429 2337 Fax: +61 2 9429 2394 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Wednesday, 17 January 2007 12:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF and ISPF/PDF I've never used ISPF, so I'm not sure what 'ISPF file tailoring' is, but if it's something like entering parameters or values of some sort, I expect it could be duplicated to a certain extent. Ed Zell wrote: Depending upon what those 'cool utilities' are they may be able to be converted to REXX and Xedit (for full screen dialog support). There are also some other full screen dialog packages available, there was a thread about that topic here some time ago. I have done that with a few apps, but we generate a ton of VSE JCL using ISPF file tailoring. I've never really found a way to get away from it that is as simple and easy as file tailoring. Any thoughts there? Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Re: ISPF and ISPF/PDF
I have done that with a few apps, but we generate a ton of VSE JCL using ISPF file tailoring. I've never really found a way to get away from it that is as simple and easy as file tailoring. Any thoughts there? CUA2001 does a lot with XEDIT, and you get the full power of XEDIT in the process. It might be close enough to get you close to the capability of the ISPF file tailoring code.
Re: DFSMS RMS ISPF
Thanks all who responded... Imler, Steven J wrote: Lee, That's correct. ISPF is *not* needed for the RMS component of DFSMS ... the component that supports the z/VM interface to the IBM 3494 Tape Library (ATL or VTS). JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Lee Stewart Sent: Tuesday, April 25, 2006 06:24 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DFSMS RMS ISPF Hi all...I must be getting old, but I seem to remember not too long ago a discussion here about installing only the RMS part of DFSMS for 3494 support and *I think* someone said you don't need ISPF for that part of DFSMS. I searched the archives several ways and couldn't find any discussion like that, so I'm asking here... Is it correct? And does anyone else remember that discussion or am I.? Thanks as always, Lee -- Lee Stewart, Senior SE Sirius Enterprise Systems Group Phone: (303) 798-2954 Fax: (720) 228-2321 [EMAIL PROTECTED] www.siriuscom.com
Re: DFSMS RMS ISPF
It is correct. We got rid of ISPF long ago (we had only installed it for the NDM product to begin with) but we do use RMS for the tape library. Shimon On 25 Apr 2006 at 16:24, Lee Stewart wrote: Hi all...I must be getting old, but I seem to remember not too long ago a discussion here about installing only the RMS part of DFSMS for 3494 support and *I think* someone said you don't need ISPF for that part of DFSMS. I searched the archives several ways and couldn't find any discussion like that, so I'm asking here... Is it correct? And does anyone else remember that discussion or am I.? Thanks as always, Lee -- Lee Stewart, Senior SE Sirius Enterprise Systems Group Phone: (303) 798-2954 Fax: (720) 228-2321 [EMAIL PROTECTED] www.siriuscom.com
Re: DFSMS RMS ISPF
Thanks Marcy Shimon... Marcy Cortes wrote: Yes, you are correct. We have several systems with just rmsonly DFSMS installed for 3494 support. See the program directory for it for it. http://www.vm.ibm.com/related/dfsms Marcy Cortes Lee Stewart, Senior SE Sirius Enterprise Systems Group Phone: (303) 798-2954 Fax: (720) 228-2321 [EMAIL PROTECTED] www.siriuscom.com
