date:20120822

Re: ISPF Panel and LPAR name

2012-08-22 Thread CM Poncelet

... 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 () 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 :
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

Re: How to retain volumes by days when VOLUME VRS is used in DFSMSrmm

2012-08-22 Thread Minoru Massaki

Hello Conley-san,

Thank you for your suggestion.

I added VOLUME VRS and next_VRS as following:
  ADDVRS  VOLUME(VTP02*)  NEXTVRS(DAYS5)
  ADDVRS  NAME(DAYS5)  DAYS  COUNT(5)

Then I wrote a data set on volume VTP029

After Housekeeping, retention date field of VTP029 was CYCL/9.
It seems to me that NEXTVRS is NO effect.

Then I changed VOLUME VRS as following.
  ADDVRS VOLUME(VTP02*)  COUNT(1)  NEXTVRS(DAYS5)

Housekeeping ran again, then the retention data of VTP029 became CYCL/1.

I don't know why NEXTVRS is NO effect.
Our VRSEL option in EDGPRMxx is VRSEL(NEW).

Are there something wrong in my specification about VRS?

Your help is appreciated.


Minoru Massaki  (M*M)
2012/8/22 Thomas Conley :
> On 8/21/2012 7:37 PM, Thomas Conley wrote:
>> On 8/21/2012 12:20 PM, Minoru Massaki wrote:
>>> Hello RMM experts,
>>>
>>> I like retain volumes (volser prefix is VTP02) 5 days by VOLUME VRS.
>>> Then I added a VOLUME VRS as following.
>>>
>>>   ADDVRS  VOLUME(VTP02*)  COUNT(5)
>>>
>>> (If I add operand DAYS to specify retention type, it became an error.
>>>IKJ56712I INVALID KEYWORD, DAYS
>>> RMM Manual says there is no DAYS operand for ADDVRS VOLUME.)
>>>
>>>
>>> I created a data set on volume VTP020, and ran RMM housekeep with
>>> VRSEL, EXPROC parms.
>>> After that I display the volume VTP020 through ISMF pannel.
>>> Retention date field of the VTP020 showed "CYCL/5", not "/ddd"
>>> (ddd=current date+5)
>>>
>>> Is this working as design or bug?
>>>
>>> I want to retain the volume 5 days long, NOT cycle 5.
>>> How can I set the retention data as current data + 5?
>>>
>>
>> Minoru,
>>
>> COUNT for a volume VRS is the number of volumes you want to retain,
>> hence the CYCL/5 on the volume retention.  Eliminate COUNT on the
>> VOLUME VRS, or specify COUNT(9), then use a NEXTVRS(DAYS) and create
>> ADDVRS DAYS5 DAYS(5).
>>
>> Regards,
>> Tom Conley
>>
>
> Sorry, that should have said NEXTVRS(DAYS5).
>
> Regards,
> Tom Conley
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 

全先　実  -  Minoru Massaki  (M*M)
E-mail: mmass...@gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Statement of general direction: IBM CICS Transaction Server for z/OS

2012-08-22 Thread R.S.

W dniu 2012-08-22 06:20, Timothy Sipples pisze:

Greg Shirey writes:

Historically, a change in version (from V1 to V2) engenders an increase in

license fees.

I think the most you can say is that a change in the version number is only
one occasion when a change in pricing could occur.

z/OS V1 and z/VSE V4 are a couple notable examples of decreases in pricing
introduced with the change in their version numbers.

In case of VSE it's reasonable: rapidly growing market, more customers,
more sites...

But seriously: lately (last year?) there was "mass" price growth in IBM,
unrelated to any version or release change.

By "mass" I mean many products affected, not big growth in terms of %
change.

--
Radoslaw Skorupka
Lodz, Poland

--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.

62 matches

Mail list logo