Re: ISPF Panel and LPAR name
Well ... subject to interpretation. For example, DOS was a lot closer to
the *original* (pre-ESA) ISPF than Microsoft Windows ever was - and DOS
was also far more efficient. The performance problems with ISPF began
post-XA with the introduction of ESA. The purpose of ESA was to allow
IBM to take control of MVS systems and prevent sysprogs from 'zapping
out' their inefficencies in order to improve performance. IBM would
never admit that, but what cares I for what they say? BTW IBM
'blacklisted' me in the 1980s for continually questioning their
objectives. But I then went to a GSE conference and confronted IBM about
ditto ... and this time in front of their customers. When the latter
started raising their hands in a 'me too' sign, IBM had no choice but to
promise to address my concerns - or to 'blacklist' their other customers
too. IBM chose the former and this resulted in their being unable to
deploy CICS/ESA for about 2 years.
But, sure, ISPF was/is a great improvement on native TSO editing etc.
('edlin' was it, or am I losing track? I have no access to a mainframe
from this machine; so I can't check). But I continue to rip (and zap)
out all the artsy-fartsy 'improvements' introduced in ESA. E.g. I do not
want drop-down menus on my screens, or panel colors etc. stored in my
profile; and I want PFK13-24 as my primary PFKeys: period.
However, I would most strongly advise you to *avoid* choosing the easy
options (mouse-pushing, Ctrl+Alt+Delete etc.) as offered in Windows -
and be, instead, familiar with reading (and, if possible, with writing)
machine code. Intel processors (upon which Windows depends) have an
unavoidably short 'shelf life', because their OP codes - i.e.
instruction sets - are inefficient. For example, each of Intel's CPU
registers (A to F, the last time I wrote Intel assembler - probably
15-17 years ago) has its own set of OP codes ... and these are further
sub-divided, e.g. in the case of the A (accumulator) register, into: AL,
AH, A and AX (if I remember). So, a simple LR (which uses the one OP
code x'18' for *all* registers on an IBM processor) requires 4 OP codes
for the A register alone on an Intel processor. But there are then still
the B to F registers, which all have their own 4 separate OP codes. If
you then add to that the AR, ALR, SR, SLR, XR, OR, NR etc. operations
... you realize that Intel processors soon run out of available OP
codes. So the next Intel 'solution' is to produce dual-core and now, I
believe, quad-core processors. But the practical limit is eight-core
processors. Beyond that, the O/S spends more time keeping track of which
part of which task it has dispatched to which processor, than it has
time to get work done. So expect some six-core and eight-core processors
from Intel - and then bye bye (although they might still be useful in
dishwashers). That is why Intel processors cost $100-200 instead of
$50K+ (for CMOS processors that is; no idea what bi-polar ones cost
these days *if* they are still available [the Hitachi Skylines were the
last to use them, in 1995, AFAIK]). But all processors are constrained
*not* to shorten their 'inter-wafer gaps' below about 14nm: otherwise
they produce unpredictable results, because of quantum effects.
Meanwhile, nobody wants to buy an unpredictable PC/lap-top/iPad/etc. -
no matter how much faster it produces unpredictable results. So Wintel's
days of using their current technology are numbered - perhaps another
15 years or so (at a rough guess) - unless they find a way to super-cool
their CPUs to around 3 degrees Kelvin without cracking them. But Wintel
won't care about that: they'll have already made their pretty penny and
will want to spend it.
As a general 'rule of thumb', I would recommend that you choose always
to do whatever is the most difficult yet doable - and leave all the easy
stuff for others. That way they turn into donkeys and you don't (as
Pinocchio might have put it).
Cheers, Chris Poncelet
Paul Gilmartin wrote:
ISPF _is_ Windows for z/OS.
On Wed, 22 Aug 2012 08:22:17 +0100, CM Poncelet wrote:
... because it is moving back towards suppressing intelligence (as Mao
Tse Tung did in China, in the 1960s). We should not all be obliged to
look at pictures just because the majority of people cannot read.
But isn't ISPF itself a large step moving TSO in the direction of what
Windows later became? And is it not suppressing intelligence to
relieve users of the burden of learning the syntax of TSO line commands?
You may continue to use the OUTPUT command if that's your preference.
I'll use SDSF.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access
Re: ISPF Panel and LPAR name
In 503ba219.7000...@bcs.org.uk, on 08/27/2012
at 05:36 PM, CM Poncelet ponce...@bcs.org.uk said:
Well ... subject to interpretation. For example, DOS was a lot closer
to the *original* (pre-ESA) ISPF than Microsoft Windows ever was
Neither looked anything like ISPF, or even like the original SPF.
The purpose of ESA was to allow IBM to take control of MVS systems
and prevent sysprogs from 'zapping out' their inefficencies in
order to improve performance.
OCO started well before ESA. I've never seen any evidence that the
purpose for ESA was anything other than VSCR.
But, sure, ISPF was/is a great improvement on native TSO editing
etc. ('edlin' was it, or am I losing track?
You're losing track; EDLIN was a PC editor.
However, I would most strongly advise you to *avoid* choosing the
easy options (mouse-pushing, Ctrl+Alt+Delete etc.) as offered in
Windows - and be, instead, familiar with reading (and, if possible,
with writing) machine code.
What do you have against assemblers?
you realize that Intel processors soon run out of available OP
codes. So the next Intel 'solution' is to produce dual-core and now,
I believe, quad-core processors.
Multi-core chips have nothing to do with running out of opcodes.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 50382f4e.6000...@bcs.org.uk, on 08/25/2012 at 02:50 AM, CM Poncelet ponce...@bcs.org.uk said: As your interpretation seems to be the only one that matters How is that not a lie? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 503996a6.8030...@bcs.org.uk, on 08/26/2012 at 04:23 AM, CM Poncelet ponce...@bcs.org.uk said: What's your problem, Metz? Dealing with hypocritical fools. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
On Sun, Aug 26, 2012 at 8:41 AM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 503996a6.8030...@bcs.org.uk, on 08/26/2012 at 04:23 AM, CM Poncelet ponce...@bcs.org.uk said: What's your problem, Metz? Dealing with hypocritical fools. http://www.youtube.com/watch?v=4ivUOnnstpg -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
What's your problem, Metz? Run out of words? I'll see you later, pussy. Eternity might be a long time, but I'm infinitely patient. Ta ta for now CM Poncelet wrote: Shmuel Metz (Seymour J.) wrote: In 50361ac9.1080...@bcs.org.uk, on 08/23/2012 at 12:58 PM, CM Poncelet ponce...@bcs.org.uk said: Solomon's Book of Proverbs, chapter 26 verse 5 Ah, the Devil quoting scripture. Original Message Subject:Re: CORRUPT PDS - I/O ERROR Date: Thu, 4 Aug 2011 20:21:52 -0400 From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net Reply-To: IBM Mainframe Discussion List ibm-m...@bama.ua.edu Organization: Atid/2 To: ibm-m...@bama.ua.edu Newsgroups: bit.listserv.ibm-main snip As your interpretation seems to be the only one that matters Liar. -- Ah, the Devil ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Tut tut. Not a mention of 'using a search engine' in my quoted reply. In fact, I use them regularly. You seem confused. Meanwhile, Germany's economy is thriving while Greece's one is on its knees. The former relies on science/engineering, the latter on art/entertainment (and on hanging dogs from trees, dousing them in parrafin oil and setting them on fire alive for 'entertainment' purposes). Du kannst mich mal am Arsch lecken. Ta ta Shmuel Metz (Seymour J.) wrote: In 50359f17.2080...@bcs.org.uk, on 08/23/2012 at 04:10 AM, CM Poncelet ponce...@bcs.org.uk said: Well ... art/entertainment v. science/engineering as in Aesop's fable about the Cicala and the Ant. Industry makes its own bread: it does not sing all summer and expect bread when winter arrives. Nonsense. Using a search engine is not remotely analogous to singing all summer. If anything, refusing to use a search engine is a manifestation of the NIH syndrome. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
But 'search engines' are for entertainment purposes - an industry runs on science and engineering, not art and entertainment. Wow, is this some kind of alternate universe thing? Date:Wed, 22 Aug 2012 08:22:17 +0100 From:CM Poncelet ponce...@bcs.org.uk Subject: Re: ISPF Panel and LPAR name ... because it is moving back towards suppressing intelligence (as Mao Tse Tung did in China, in the 1960s). We should not all be obliged to look at pictures just because the majority of people cannot read. Yes, I understand the usefulness of Google's query completion etc. But 'search engines' are for entertainment purposes - and industry runs on science and engineering, not art and entertainment. You need to type the dataset name on every ISPF panel only because you are still invoking IBM's 'demo' (now default/'de facto') panels. You can bypass ISR@PRIM at logon and display your own panels instead - then store, retrieve and display in them the datasets you want to access, e.g. by a VGET (all DSNs) on initial display of your panels and by a VPUT to save them (and any changes to them) on exit, from/to your profile pool. If you then take copies of the default ISPF panels, add to them the name of a variable which contains the DSN you want to process (and that is stored in your panels, e.g. DSNA) - and you then save these modified ISPF panels in a dataset concatenated ahead of the default one on ISPPLIB - they will now be the ones that are displayed. If you next create TSO commands (in a table in ISPTLIB) which are associated with the ISPF functions you want to invoke (passing e.g. DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 'ED' for Edit etc.), your modified ISPF panels will now contain your selected DSN. If you set PANELID ON, you will see the names of which panels you need to copy and modify. Admittedly, there is a bit more to it than that; but I'm sure you can figure it out. BTW Bear in mind that Google now tracks everywhere you go on the web ... and then sells your info to advertisers wry grin: http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html Cheers, Chris Poncelet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Not quite. The 'real universe' produces the bread; the 'alternate universe' eats it. Cheers, CP David Stokes wrote: But 'search engines' are for entertainment purposes - an industry runs on science and engineering, not art and entertainment. Wow, is this some kind of alternate universe thing? Date:Wed, 22 Aug 2012 08:22:17 +0100 From:CM Poncelet ponce...@bcs.org.uk Subject: Re: ISPF Panel and LPAR name ... because it is moving back towards suppressing intelligence (as Mao Tse Tung did in China, in the 1960s). We should not all be obliged to look at pictures just because the majority of people cannot read. Yes, I understand the usefulness of Google's query completion etc. But 'search engines' are for entertainment purposes - and industry runs on science and engineering, not art and entertainment. You need to type the dataset name on every ISPF panel only because you are still invoking IBM's 'demo' (now default/'de facto') panels. You can bypass ISR@PRIM at logon and display your own panels instead - then store, retrieve and display in them the datasets you want to access, e.g. by a VGET (all DSNs) on initial display of your panels and by a VPUT to save them (and any changes to them) on exit, from/to your profile pool. If you then take copies of the default ISPF panels, add to them the name of a variable which contains the DSN you want to process (and that is stored in your panels, e.g. DSNA) - and you then save these modified ISPF panels in a dataset concatenated ahead of the default one on ISPPLIB - they will now be the ones that are displayed. If you next create TSO commands (in a table in ISPTLIB) which are associated with the ISPF functions you want to invoke (passing e.g. DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 'ED' for Edit etc.), your modified ISPF panels will now contain your selected DSN. If you set PANELID ON, you will see the names of which panels you need to copy and modify. Admittedly, there is a bit more to it than that; but I'm sure you can figure it out. BTW Bear in mind that Google now tracks everywhere you go on the web ... and then sells your info to advertisers wry grin: http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html Cheers, Chris Poncelet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Solomon's Book of Proverbs, chapter 26 verse 5 Shmuel Metz (Seymour J.) wrote: In 50342f7d.6030...@bcs.org.uk, on 08/22/2012 at 02:01 AM, CM Poncelet ponce...@bcs.org.uk said: Is that so? Yes, they know what they are doing and why. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 645893134704.wa.paulgboulderaim@listserv.ua.edu, on 08/22/2012 at 09:36 AM, Paul Gilmartin paulgboul...@aim.com said: But isn't ISPF itself a large step moving TSO in the direction of what Windows later became? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In offadfa57b.19e8601a-on85257a62.0050ea48-85257a62.0051d...@tsys.com, on 08/22/2012 at 10:54 AM, Kirk Talman rkueb...@tsys.com said: More accurately a session manager is Windows for z/OS. Not even close. While I have had issues with TPX, the comparison is still insulting. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 50359f17.2080...@bcs.org.uk, on 08/23/2012 at 04:10 AM, CM Poncelet ponce...@bcs.org.uk said: Well ... art/entertainment v. science/engineering as in Aesop's fable about the Cicala and the Ant. Industry makes its own bread: it does not sing all summer and expect bread when winter arrives. Nonsense. Using a search engine is not remotely analogous to singing all summer. If anything, refusing to use a search engine is a manifestation of the NIH syndrome. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 50361ac9.1080...@bcs.org.uk, on 08/23/2012 at 12:58 PM, CM Poncelet ponce...@bcs.org.uk said: Solomon's Book of Proverbs, chapter 26 verse 5 Ah, the Devil quoting scripture. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
... because it is moving back towards suppressing intelligence (as Mao Tse Tung did in China, in the 1960s). We should not all be obliged to look at pictures just because the majority of people cannot read. Yes, I understand the usefulness of Google's query completion etc. But 'search engines' are for entertainment purposes - and industry runs on science and engineering, not art and entertainment. You need to type the dataset name on every ISPF panel only because you are still invoking IBM's 'demo' (now default/'de facto') panels. You can bypass ISR@PRIM at logon and display your own panels instead - then store, retrieve and display in them the datasets you want to access, e.g. by a VGET (all DSNs) on initial display of your panels and by a VPUT to save them (and any changes to them) on exit, from/to your profile pool. If you then take copies of the default ISPF panels, add to them the name of a variable which contains the DSN you want to process (and that is stored in your panels, e.g. DSNA) - and you then save these modified ISPF panels in a dataset concatenated ahead of the default one on ISPPLIB - they will now be the ones that are displayed. If you next create TSO commands (in a table in ISPTLIB) which are associated with the ISPF functions you want to invoke (passing e.g. DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 'ED' for Edit etc.), your modified ISPF panels will now contain your selected DSN. If you set PANELID ON, you will see the names of which panels you need to copy and modify. Admittedly, there is a bit more to it than that; but I'm sure you can figure it out. BTW Bear in mind that Google now tracks everywhere you go on the web ... and then sells your info to advertisers wry grin: http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html Cheers, Chris Poncelet Paul Gilmartin wrote: On Wed, 22 Aug 2012 04:57:25 +0100, CM Poncelet wrote: IBM have recognized that 99% of users are computer illiterate, but have 99% of the money. So they are following Microsoft's 'lead' and, step-by-step, implementing Windoze for mainframes. And this, were it to happen, would be entirely a Bad Thing because ...? I love Google's query completion. As soon as I've typed 3 characters in the text box, it presents me with a dropdown menu of a handful of plausible completions (all wrong). A few more keystrokes and it shows me the one I want, among others, not only on Windows, but likewise on OS X and Linux. This is not a bad thing. And it would be a good thing (disputed only by laudator temporis acti ©) if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. And spelling correction. I like the way Google presents me an option; I detest the way Firefox makes the correction, willy-nilly. It could be done well. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 50342f7d.6030...@bcs.org.uk, on 08/22/2012 at 02:01 AM, CM Poncelet ponce...@bcs.org.uk said: Is that so? Yes, they know what they are doing and why. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
ISPF _is_ Windows for z/OS. On Wed, 22 Aug 2012 08:22:17 +0100, CM Poncelet wrote: ... because it is moving back towards suppressing intelligence (as Mao Tse Tung did in China, in the 1960s). We should not all be obliged to look at pictures just because the majority of people cannot read. But isn't ISPF itself a large step moving TSO in the direction of what Windows later became? And is it not suppressing intelligence to relieve users of the burden of learning the syntax of TSO line commands? You may continue to use the OUTPUT command if that's your preference. I'll use SDSF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Paul Gilmartin wrote: I love Google's query completion. And it would be a good thing if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. ISPF already supports auto-completion of data set names (kinda sorta), but it's extremely clunky. Better and easier to use SimpList and not have to type anything at all. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Wed, 22 Aug 2012 08:22:17 +0100 From: ponce...@bcs.org.uk Subject: Re: ISPF Panel and LPAR name To: IBM-MAIN@LISTSERV.UA.EDU ... because it is moving back towards suppressing intelligence (as Mao Tse Tung did in China, in the 1960s). We should not all be obliged to look at pictures just because the majority of people cannot read. Yes, I understand the usefulness of Google's query completion etc. But 'search engines' are for entertainment purposes - and industry runs on science and engineering, not art and entertainment. You need to type the dataset name on every ISPF panel only because you are still invoking IBM's 'demo' (now default/'de facto') panels. You can bypass ISR@PRIM at logon and display your own panels instead - then store, retrieve and display in them the datasets you want to access, e.g. by a VGET (all DSNs) on initial display of your panels and by a VPUT to save them (and any changes to them) on exit, from/to your profile pool. If you then take copies of the default ISPF panels, add to them the name of a variable which contains the DSN you want to process (and that is stored in your panels, e.g. DSNA) - and you then save these modified ISPF panels in a dataset concatenated ahead of the default one on ISPPLIB - they will now be the ones that are displayed. If you next create TSO commands (in a table in ISPTLIB) which are associated with the ISPF functions you want to invoke (passing e.g. DSNA to them), then issue your TSO commands (e.g. 'BR' for Browse or 'ED' for Edit etc.), your modified ISPF panels will now contain your selected DSN. If you set PANELID ON, you will see the names of which panels you need to copy and modify. Admittedly, there is a bit more to it than that; but I'm sure you can figure it out. BTW Bear in mind that Google now tracks everywhere you go on the web ... and then sells your info to advertisers wry grin: http://www.dailymail.co.uk/sciencetech/article-2105435/Three-simple-steps-delete-Google-browsing-history--late.html Cheers, Chris Poncelet Paul Gilmartin wrote: On Wed, 22 Aug 2012 04:57:25 +0100, CM Poncelet wrote: IBM have recognized that 99% of users are computer illiterate, but have 99% of the money. So they are following Microsoft's 'lead' and, step-by-step, implementing Windoze for mainframes. And this, were it to happen, would be entirely a Bad Thing because ...? I love Google's query completion. As soon as I've typed 3 characters in the text box, it presents me with a dropdown menu of a handful of plausible completions (all wrong). A few more keystrokes and it shows me the one I want, among others, not only on Windows, but likewise on OS X and Linux. This is not a bad thing. And it would be a good thing (disputed only by laudator temporis acti ©) if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. And spelling correction. I like the way Google presents me an option; I detest the way Firefox makes the correction, willy-nilly. It could be done well. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
On 8/22/2012 at 03:22 AM, CM Poncelet ponce...@bcs.org.uk wrote: Yes, I understand the usefulness of Google's query completion etc. But 'search engines' are for entertainment purposes - and industry runs on science and engineering, not art and entertainment. What a severely limited understanding of reality this comment shows. http://www.bbc.co.uk/news/magazine-19291258 Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Can I throw away my keyboard and use only my mouse? On Wed, 22 Aug 2012 11:02:36 -0400, Dave Salt wrote: Paul Gilmartin wrote: I love Google's query completion. And it would be a good thing if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. ISPF already supports auto-completion of data set names (kinda sorta), but it's extremely clunky. Better and easier to use SimpList and not have to type anything at all. Dave Salt Sometimes it might be less tedious to type than to use point-and-shoot (is that what you mean?) to drill down through a hierarchy of data set names. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
As long as you always have a GUI on screen keyboard. Heck, get an iPad or touch screen device and throw away the mouse too. On Wed, Aug 22, 2012 at 5:51 PM, Paul Gilmartin paulgboul...@aim.com wrote: Can I throw away my keyboard and use only my mouse? On Wed, 22 Aug 2012 11:02:36 -0400, Dave Salt wrote: Paul Gilmartin wrote: I love Google's query completion. And it would be a good thing if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. ISPF already supports auto-completion of data set names (kinda sorta), but it's extremely clunky. Better and easier to use SimpList and not have to type anything at all. Dave Salt Sometimes it might be less tedious to type than to use point-and-shoot (is that what you mean?) to drill down through a hierarchy of data set names. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Well now IBM's position on reports (dasd usage) was to do just that. To back that up at GUIDE we had repeatedly put in request (requirements) for reports on DASD usage and they were continually rejected. After at least 3 attempts the verbiage came back to run ISMF in batch (which did not meet the entire request BTW). We gave up. Ed On Aug 22, 2012, at 12:02 AM, CM Poncelet wrote: Sure. But I am not advocating running ISPF in batch other than as an 'adhoc' and occasional measure, just to save time. It is a lot quicker than typing. (My next 'fastest' solution would be to use SELCOPY.) If it's the CPU clock that matters - and it usually is - the code should be written in assembler. Gibney, Dave wrote: Take a look at ISMF's Naviquest. ISPF can work in batch. It uses a lot of cpu, but it does work. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of CM Poncelet Sent: Monday, August 20, 2012 10:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Panel and LPAR name Batch Clist/REXX does not use panels. They are intended for *interactive* TSO/ISPF dialogs. Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. BTW Beware of embedded LIBDEFs in Clist/REXX. Code PASSLIB on ISPSTART to avoid deallocating all datasets (not just the LIBDEF'd ones) from a DDNAME on the final LIBDEF. Also, DDNAME=ISPPROF can be allocated as a temporary empty PDS in batch (e.g. for VPUT/VGETs to PROFILE, although ditto to SHARED will work too). But I would recommend that you then code NEWAPPL(whatever, e.g. ASMX) on ISPSTART ... just in case ISPF allocates its own profiles in your ISPPROF and your Clist/REXX then has to share its profile data with ISPF by default. I never bothered to check what actually happens: but ISPF does not recognize ISPPROF members ASMXPROF/EDIT/EDRT and will therefore not try to update them. E.g. ISPSTART CMD(%TEST ... any parms) NEWAPPL(ABCD) PASSLIB. Invoking programs (as opposed to commands) from batch Clist/REXX can be done via e.g. ISPSTART PGM(IEBCOPY) NEWAPPL(whatever) PASSLIB - but it would be more efficient to invoke the programs directly. CP Paul Gilmartin wrote: On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil --- --- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
From: ds...@hotmail.com ISPF already supports auto-completion of data set names (kinda sorta), but it's extremely clunky. Better and easier to use SimpList and not have to type anything at all. From: paulgboul...@aim.com Can I throw away my keyboard and use only my mouse? It's very rare that a SimpList user needs to use a keyboard, except of course for editing data. Other than that, almost everything can be done with a mouse. For example, a user can switch from one list of objects (such as UNIX files, DB2 tables, IMS databases, ISPF commands, etc) to another list of objects (such as data sets, PC files, VSAM files, TSO commands, etc), scroll up or down the list of objects, select any object from the list (such as a PDS), locate a member in the list, and open the member for any function (e.g. browse, edit, copy, transfer, etc), all without ever touching a keyboard. Sometimes it might be less tedious to type than to use point-and-shoot (is that what you mean?) to drill down through a hierarchy of data set names. The option to use a keyboard or mouse is always available. Some people prefer using a keyboard while others prefer using a mouse. One SimpList user said that when he started using SimpList and began using a mouse it cured the repetitive stress injury he had in his wrist. As for drilling down through a hierarchy of data set names, that's not the way most people use SimpList. Instead, commonly used object names are stored in one of 26 lists, each of which is represented by a letter of the alphabet (A-Z). For example, COBOL data sets might be stored on list 'C' and JCL data sets stored on list 'J' and UNIX files stored on list 'U' (etc). Let's say a user is on list 'L' (which might contain a list of Load Libraries) and they want to select one of the REXX libraries they've stored on list 'R'. If the REXX library has a label (see below) it can be opened directly by simply entering the label name on the command line. Otherwise, the user can click the REXX index name to switch to the list of REXX libraries and then click whichever REXX library they want to open. In other words, any object can usually be opened with a single command or a couple of mouse clicks. Any type of object (such as a data set, UNIX file, DB2 table, etc) can be given a user defined alias known as a label. A label begins with a period followed by 1 to 8 characters. For example, 'SOME.LONG.PROD.COBOL.DATASET.NAME' could be given a label called .PCOB or .PRODCOB (etc). Any object that has a label can be opened from ANY command line, anywhere in ISPF. For example, if I'm in the middle of an SDSF session and I want to browse the production COBOL library I can enter BR .PCOB on the command line. In summary, virtually any type of object can be opened almost instantly, from anywhere in ISPF, with no need to navigate through different panels or drill down through any type of hierarchy. It might not be quite as slick as the Google search auto-complete, but it does save people a heck of a lot of time! Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
From: ponce...@bcs.org.uk Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. The company I worked for had a vendor product (Endevor) that performed various functions using ISPF panels. Management wanted some of the functions to be executed in batch, so I customized the panels to recognize a parameter that would only be passed in batch. When the panel was invoked with the parameter it filled in various fields automatically and simulated ENTER being pressed, which invoked the next panel (and so on). Some of these processes went quite a few panels deep and the whole thing worked flawlessly. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Paul Gilmartin wrote: On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Take a look at ISMF's Naviquest. ISPF can work in batch. It uses a lot of cpu, but it does work. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of CM Poncelet Sent: Monday, August 20, 2012 10:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Panel and LPAR name Batch Clist/REXX does not use panels. They are intended for *interactive* TSO/ISPF dialogs. Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. BTW Beware of embedded LIBDEFs in Clist/REXX. Code PASSLIB on ISPSTART to avoid deallocating all datasets (not just the LIBDEF'd ones) from a DDNAME on the final LIBDEF. Also, DDNAME=ISPPROF can be allocated as a temporary empty PDS in batch (e.g. for VPUT/VGETs to PROFILE, although ditto to SHARED will work too). But I would recommend that you then code NEWAPPL(whatever, e.g. ASMX) on ISPSTART ... just in case ISPF allocates its own profiles in your ISPPROF and your Clist/REXX then has to share its profile data with ISPF by default. I never bothered to check what actually happens: but ISPF does not recognize ISPPROF members ASMXPROF/EDIT/EDRT and will therefore not try to update them. E.g. ISPSTART CMD(%TEST ... any parms) NEWAPPL(ABCD) PASSLIB. Invoking programs (as opposed to commands) from batch Clist/REXX can be done via e.g. ISPSTART PGM(IEBCOPY) NEWAPPL(whatever) PASSLIB - but it would be more efficient to invoke the programs directly. CP Paul Gilmartin wrote: On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 6419321491215114.wa.paulgboulderaim@listserv.ua.edu, on 08/20/2012 at 07:57 AM, Paul Gilmartin paulgboul...@aim.com said: There are contrary valid points of view here: Perhaps on what is desirable, but the behavior of the ISPF code is a matter of fact. o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Shmuel Metz (Seymour J.) wrote: Batch Clist/REXX does not use panels. Foreground Clist/REXX does not use panels. True, but see below. Both batch and foreground scripts called from ISPF can use ISPF services, including panels. Fact is - both are, like you say, using services (including, panels, message libraries, skeletons, etc) which are open and available if allocated correctly previously. If you can write something properly, you can use panels in batch or interactively. You need to convey input to output in one way or other. BTGTS. Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. ROTF,LMAO! That a funny way to write that they know more than you do. :-D Fact is - a third [which shall remain nameless] party product is using what they called 'keystroke language' and that is using batch emulation of Clist/REXX panels. It is working properly, based on a good understanding of VTAM logmodes. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
From: paulgboul...@aim.com For that to be an optimum solution, the panels must have been heavy on procedure and light on display. On the contrary, some of the vendor panels were VERY heavy on display. So heavy in fact that it was extremely easy for someone to slip up and fill in one or more fields on one or more panels incorrectly. Even worse, many of the fields on the panels always reverted back to their default values instead of the values the person had last typed in. This not only caused errors, but was extremely frustrating for the people who had to work with the vendor product. The 'optimum solution' might have been to work with the vendor to redesign their product to meet the unique requirements of the company I worked for. But that could have taken months or years, and meanwhile the product users were ready to revolt. So, I created a front-end panel that prompted the users for a minimum amount of information, which was then used to drive the vendor panels in batch. The net result was an extremely simplified process that was very easy to use, with far less time being spent fixing mistakes. I'm not saying this solution was optimal, but it worked well and it certainly provides an example of how and why ISPF panels might be used in batch. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 21 Aug 2012 10:08:32 -0500 From: paulgboul...@aim.com Subject: Re: ISPF Panel and LPAR name To: IBM-MAIN@LISTSERV.UA.EDU On Tue, 21 Aug 2012 02:43:58 -0400, Dave Salt wrote: From: ponce...@bcs.org.uk Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. ... I customized the panels to recognize a parameter that would only be passed in batch. When the panel was invoked with the parameter it filled in various fields automatically and simulated ENTER being pressed, which invoked the next panel (and so on). Some of these processes went quite a few panels deep and the whole thing worked flawlessly. I'll stand corrected from my previous ply. That's bizarre! Byzantine. For that to be an optimum solution, the panels must have been heavy on procedure and light on display. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Is that so? Shmuel Metz (Seymour J.) wrote: In 50332317.4040...@bcs.org.uk, on 08/21/2012 at 06:56 AM, CM Poncelet ponce...@bcs.org.uk said: Batch Clist/REXX does not use panels. Foreground Clist/REXX does not use panels. Both batch and foreground scripts called from ISPF can use ISPF services, including panels. Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. ROTF,LMAO! That a funny way to write that they know more than you do. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
IBM have recognized that 99% of users are computer illiterate, but have 99% of the money. So they are following Microsoft's 'lead' and, step-by-step, implementing Windoze for mainframes. Other vendors are just following suit. But the remaining 1% of users (with 1% of the money) can still figure out how to avoid becoming panel-filling typists. Thanks for the info. Great stuff. Cheers, Chris Poncelet Dave Salt wrote: From: ponce...@bcs.org.uk Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. The company I worked for had a vendor product (Endevor) that performed various functions using ISPF panels. Management wanted some of the functions to be executed in batch, so I customized the panels to recognize a parameter that would only be passed in batch. When the panel was invoked with the parameter it filled in various fields automatically and simulated ENTER being pressed, which invoked the next panel (and so on). Some of these processes went quite a few panels deep and the whole thing worked flawlessly. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Paul Gilmartin wrote: On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
On Wed, 22 Aug 2012 04:57:25 +0100, CM Poncelet wrote: IBM have recognized that 99% of users are computer illiterate, but have 99% of the money. So they are following Microsoft's 'lead' and, step-by-step, implementing Windoze for mainframes. And this, were it to happen, would be entirely a Bad Thing because ...? I love Google's query completion. As soon as I've typed 3 characters in the text box, it presents me with a dropdown menu of a handful of plausible completions (all wrong). A few more keystrokes and it shows me the one I want, among others, not only on Windows, but likewise on OS X and Linux. This is not a bad thing. And it would be a good thing (disputed only by laudator temporis acti ©) if ISPF were to do similarly on every panel which allows a data set name to be typed. I suspect Dave S. can explain to us why this is unlikely to happen soon if ever. And spelling correction. I like the way Google presents me an option; I detest the way Firefox makes the correction, willy-nilly. It could be done well. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Sure. But I am not advocating running ISPF in batch other than as an 'adhoc' and occasional measure, just to save time. It is a lot quicker than typing. (My next 'fastest' solution would be to use SELCOPY.) If it's the CPU clock that matters - and it usually is - the code should be written in assembler. Gibney, Dave wrote: Take a look at ISMF's Naviquest. ISPF can work in batch. It uses a lot of cpu, but it does work. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of CM Poncelet Sent: Monday, August 20, 2012 10:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Panel and LPAR name Batch Clist/REXX does not use panels. They are intended for *interactive* TSO/ISPF dialogs. Anyone who writes Clist/REXX that invokes panels in batch doesn't have a clue about what he/she/it is doing. BTW Beware of embedded LIBDEFs in Clist/REXX. Code PASSLIB on ISPSTART to avoid deallocating all datasets (not just the LIBDEF'd ones) from a DDNAME on the final LIBDEF. Also, DDNAME=ISPPROF can be allocated as a temporary empty PDS in batch (e.g. for VPUT/VGETs to PROFILE, although ditto to SHARED will work too). But I would recommend that you then code NEWAPPL(whatever, e.g. ASMX) on ISPSTART ... just in case ISPF allocates its own profiles in your ISPPROF and your Clist/REXX then has to share its profile data with ISPF by default. I never bothered to check what actually happens: but ISPF does not recognize ISPPROF members ASMXPROF/EDIT/EDRT and will therefore not try to update them. E.g. ISPSTART CMD(%TEST ... any parms) NEWAPPL(ABCD) PASSLIB. Invoking programs (as opposed to commands) from batch Clist/REXX can be done via e.g. ISPSTART PGM(IEBCOPY) NEWAPPL(whatever) PASSLIB - but it would be more efficient to invoke the programs directly. CP Paul Gilmartin wrote: On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Doug Nadel has an edit macro called BATCHPDF which will create the DD names for running ISPF in batch. I like it and use it, at least to get me started. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of CM Poncelet Sent: Monday, August 20, 2012 4:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Panel and LPAR name Gosh. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
On Mon, 20 Aug 2012 02:01:57 +0100, CM Poncelet wrote: Gosh. The ISPPLIB DD must be allocated in the JCL. No; a dynamic allocation before ISPSTART will work just as well. There are contrary valid points of view here: o Not to require the programmer to provide resources he doesn't intend to use. o To require the programmer to supply in advance all resources he might potentially use, in order to preclude a failure later in the process. ISPF apparently elects the latter; many programs elect the former e.g. with respect to SYSLIB DD. Fortunately, ISPF doesn't require that a display be available when the programmer intends not to use one. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In of1a25d1f0.ca6c550d-on88257a5d.0014c951-88257a5d.00157...@sce.com, on 08/16/2012 at 08:54 PM, Skip Robinson jo.skip.robin...@sce.com said: IIRC ISPF in batch requires all the standard DD allocations or it just won't work at all. Period. Yes, except that they can be dynamic rather than DD. If you have an allocation script that you run in foreground to allocate ISPF datasets, you may be able to run the same script in background. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Use VPUT to save in your REXX exec; use VGET to retrieve in your panel )INIT section. If the same rexx script then does an ISPEXEC DISPLAY, the VPUT is not needed. ISPF will find the variable in the rexx's function pool. If you want to display the value in other panels not displayed from this rexx, you'll need to VPUT... SHARED. In neither of the above cases is the VGET in the panel needed. ISPF will use the variable from the function pool, if it finds one there. Otherwise it will search the SHARED pool (then the PROFILE pool, which is not of interest here). If the panel is displayed using ISPEXEC SELECT (a selection panel), then the VPUT...SHARED is needed in the rexx code. No VGET is needed in the panel. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
In 7695765772818059.wa.paulgboulderaim@listserv.ua.edu, on 08/15/2012 at 06:37 PM, Paul Gilmartin paulgboul...@aim.com said: Do batch ISPF jobs use panels? Yes. How, By specifying the panel on the ISPSTART. and is it necessary? Yes. It seems almost a contradiction in terms. No. Likewise, in noninteractive contexts I always allocate ISPPROF to DUMMY Why not a temporary? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
I think the answer may be simpler (if less satisfying) than the suggestions so far. IIRC ISPF in batch requires all the standard DD allocations or it just won't work at all. Period. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/16/2012 05:45 PM Subject:Re: ISPF Panel and LPAR name Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In 9020372708201614.wa.paulgboulderaim@listserv.ua.edu, on 08/16/2012 at 12:34 PM, Paul Gilmartin paulgboul...@aim.com said: That was in the sense of, What chore, otherwise impossible in batch, is made possible by using panels? The naswer won't satisfy you: any application written around panels. That might be using interactive panels through WSA, it might be panels with processing logic or it might be something I haven't even thought of. -- Shmuel (Seymour J.) Metz, SysProg and JOAT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
That's how we do it. Every tweak to an IBM supplied panel is implemented via SMP/E usermod. That way we get a MODID error at APPLY time and know when we have to reconcile updates. For a new release, we plow through our usermod library from top to bottom and (re)install every one after suitable review. The process works very well. I wholeheartedly agree that user complaint over superfluous changes is more noisome than occasional usermod reworks. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Art Gutowski arthur.gutow...@compuware.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/15/2012 11:18 AM Subject:Re: ISPF Panel and LPAR name Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Wed, 15 Aug 2012 12:51:47 -0400, Dave Salt ds...@hotmail.com wrote: Customizing the ISPF menu (ISR@PRIM) can lead to problems if people forget to update it when IBM makes changes to it. [...] If you package your changes in a USERMOD, it's not a big risk. Notwithstanding full system replacement deliveries, you'll know when it needs to be reviewed. At that, if you have even mildly astute system programmers, this is reviewed and carried forward at upgrade intervals. I never found this a hardship. In my travels, FWIW, I got a lot more guff from end-users being forced extra keystrokes and a front-end menu than I did from fellow sysprogs who had to review one of a dozen or more USERMODs once every year or two. I've had more pitfalls with programmers replicating and customizing panels in their own libraries - and there's no stopping it. If you're going to insert ISP@MSTR in front of ISR@PRIM, you'd do well to notify and give your applications teams sufficient time to review and update any batch ISPF jobs. Regards, Art Gutowski Compuware Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
I didn't know you allocate ISPPROF to DUMMY in batch. I've always used a temporary data set to achieve the same goals. //ISPPROF DD SPACE=(TRK,(1,1,2)),UNIT=SYSALLDA,DCB=SYS1.PROCLIB . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/15/2012 04:37 PM Subject:Re: ISPF Panel and LPAR name Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU snip Likewise, in noninteractive contexts I always allocate ISPPROF to DUMMY so that: o I avoid ENQ conflicts o I'm protected from idiosyncrasies of the users' profiles. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
On Wed, 15 Aug 2012 17:15:21 -0700, Skip Robinson wrote: I didn't know you allocate ISPPROF to DUMMY in batch. I've always used a temporary data set to achieve the same goals. //ISPPROF DD SPACE=(TRK,(1,1,2)),UNIT=SYSALLDA,DCB=SYS1.PROCLIB I stand corrected; I just reviewed my own code. It's: //ISPPROFDD UNIT=VIO,SPACE=(TRK,(10,0,5)),DSN=amp;ISPPROF, I suppose there are different flavors of nothing, and some nothings are too nothing for ISPF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Why not use the ISPF var for LPAR? It is SYSZNODE, SYSZPLEX, I think. If you have not done so, there is an ISPF Newsgroup that is probably a good place to ask these types of questions. Lizette -Original Message- From: Pesce, Andy andy.pe...@autozone.com Sent: Aug 14, 2012 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Panel and LPAR name I have a primary option menu (ISR@PRIM) that I am trying to put the LPAR NAME on it instead of the ZSYSID. My logon PROC executes a CLIST that does all my allocations for me. I found a REXX to run that will extract the information. However, how do I save that into a variable that I can use by my panel. Any suggestions would be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Panel and LPAR name
Oh, forgot one - ZSYSID Lizette -Original Message- From: Pesce, Andy andy.pe...@autozone.com Sent: Aug 14, 2012 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Panel and LPAR name I have a primary option menu (ISR@PRIM) that I am trying to put the LPAR NAME on it instead of the ZSYSID. My logon PROC executes a CLIST that does all my allocations for me. I found a REXX to run that will extract the information. However, how do I save that into a variable that I can use by my panel. Any suggestions would be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
