date:20120516

Frank Yaeger wrote:

Just a note to let everyone know I'll be retiring at the end of this month 
(5/31/2012).  I've been with IBM for 43+ years (plus a couple of summers in 
college) and I've enjoyed my career immensely.  I've especially enjoyed being 
able to help people use the DFSORT/ICETOOL functions I developed, over many 
years, in new and interesting ways.

Oh, no! Thats SORTa cruel to leave us! :-)

I wish to say a big THANK YOU for sorting out all our problems on IBM-MAIN, 
RACF-L and other lists. You have saved our skins too many times over the years.

All of the very best for you and your family while we will sort out your other 
colleagues who still have to sort out a work life. ;-)

I'm happy to say that others on the DFSORT Team will continue to contribute.

Could you introduce them to us?

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Perhaps some future archeologist will discover a new SORT thingy when they dig 
up RACF (Yes!), IBM, z/OS, DFSORT and ICETOOL... I would like to see their 
faces upon this discovery! :-)

Groete / Greetings
Elardus Engelbrecht

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Rob Scott

Frank

You were one of the first IBMers I ever saw that went *way* beyond the call of 
duty to help others.

You will be missed.

Enjoy your retirement!

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Frank Yaeger
Sent: 16 May 2012 02:00
To: IBM-MAIN@bama.ua.edu
Subject: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end of this month 
(5/31/2012).  I've been with IBM for 43+ years (plus a couple of summers in 
college) and I've enjoyed my career immensely.  I've especially enjoyed being 
able to help people use the DFSORT/ICETOOL functions I developed, over many 
years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I won't have access 
to a mainframe to test them, and I don't like posting untested solutions.  I 
may lurk a bit or I may not.

I'm looking forward to retirement, but I'll also miss this list.  I'm happy to 
say that others on the DFSORT Team will continue to contribute.

Thanks to everyone for giving me the chance to earn a living all these years 
doing something that was a lot of fun for me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Walter Marguccio

 From: Frank Yaeger yae...@us.ibm.com

 Just a note to let everyone know I'll be retiring at the end
 of this month (5/31/2012).  I've been with IBM for 43+ years
 
Frank,

all the best to you, and a huge thanks for all your help, support
and DFSORT tricks you have been providing.
You will be missed.


Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

Robert Prins wrote:

Can anyone skilled in the art tell me why a compiler that probably dates back 
to the late 1970'ies or early 1980'ies generates the following short and sweet 
code for a PL/I BY NAME assignment, while the not completely new (but still 
fairly recent) version of Enterprise PL/I (V3R9) generates the very, very, 
very long-winded code below it?

I'm not skilled in this art, but is your Enterprise PL/I (v3r9) also using 
Language Environment or not? 


Then again, I always thought that the fastest instructions are those ones that 
are never executed...

Those instructions don't need to be optimized... :-)

Groete / Greetings
Elardus Engelbrecht

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread David Crayford


Robert,

I'm no expert but I have read that newer hardware models (Z10 and above) 
are essentially RISC processors that run complex instructions in 
millicode. In the
case of a MVC instruction it would have to do that in a loop which would 
require branching, the enemy of pipelined exeuction units. It's also 
possible to run simple instructions
in parallel. It's plausible an MVC instruction can be executed more 
efficiently as a sequence of LG/STG instructions.
The OOO decode units do this for you with instruction cracking on a 
z196, it seems that on a  z10 the optimizer is doing the same thing.


See this document - page 21 
http://www-01.ibm.com/software/htp/tpf/tpfug/tgf11/How_do_you_do_when_youre_a_z196_CPU.pdf


Optimizers create arcane code. It's almost impossible to verify without 
understanding the secret sauce. A lot of the code the optimizers spit 
out is intractable,

and it's almost a paradox that a longer code path produces faster code.

If you don't like it you can always compile at a different ARCH() level 
and ask IBM.


On 16/05/2012 4:07 AM, Robert Prins wrote:

Can anyone skilled in the art tell me why a compiler that probably
dates back to the late 1970'ies or early 1980'ies generates the
following short and sweet code for a PL/I BY NAME assignment, while
the not completely new (but still fairly recent) version of Enterprise
PL/I (V3R9) generates the very, very, very long-winded code below it?
Or is this (V3R9) code (that predates the OOO z196 architecture)
really faster?

OS PL/I V2.3.0 - OPT(2)
  343   1  2  REPT_LINE= REPT_LIST, BY NAME;

* STATEMENT NUMBER  343
002664  58 70 8 268L 7,REPT_WORK.LINE_PTR
002668  58 60 8 030L 6,REPT_WORK.REPT_PTR
00266C  58 F0 3 600L 15,1536(0,3)
002670  D2 03 7 003 F B54  MVC   REPT_LINE.TR(4),2900(15)
002676  DE 03 7 003 6 00C  EDREPT_LINE.TR(4),REPT_LIST.TR
00267C  D2 03 7 00A F B54  MVC   REPT_LINE.RE(4),2900(15)
002682  DE 03 7 00A 6 00E  EDREPT_LINE.RI(4),REPT_LIST.RI
002688  D2 02 7 011 6 010  MVC   REPT_LINE.DA(3),REPT_LIST.DA
00268E  58 E0 3 608L 14,1544(0,3)
002692  D2 06 4 158 E 5D4  MVC   344(7,4),1492(14)
002698  DE 06 4 158 6 014  ED344(7,4),REPT_LIST.K+1
00269E  D2 05 7 017 4 159  MVC   REPT_LINE.K(6),345(4)
0026A4  D2 06 4 158 E 5D4  MVC   344(7,4),1492(14)
0026AA  DE 06 4 158 6 01B  ED344(7,4),REPT_LIST.V
0026B0  D2 04 7 028 4 15A  MVC   REPT_LINE.V(5),346(4)
0026B6  D2 03 7 030 6 026  MVC   REPT_LINE.NA(4),REPT_LIST.NA
0026BC  D2 03 7 036 6 02A  MVC   REPT_LINE.TY(4),REPT_LIST.TY
0026C2  D2 03 7 03D 6 02E  MVC   REPT_LINE.CO(4),REPT_LIST.CO
0026C8  D2 00 7 04B 6 036  MVC   REPT_LINE.SP(1),REPT_LIST.SP
0026CE  D2 03 7 05F 6 043  MVC   REPT_LINE.DATE.YEAR(4),REPT_LIST.DATE.YEAR
0026D4  D2 01 7 064 6 047  MVC   REPT_LINE.DATE.MONTH(2),REPT_LIST.DATE.MONTH
0026DA  D2 01 7 067 6 049  MVC   REPT_LINE.DATE.DAY(2),REPT_LIST.DATE.DAY

Enterprise PL/I for z/OS   V3.R9.M0 (Built:20100923) - OPT(3)
 3120.0 368  1  2   rept_line= rept_list, by name;

003E40  E350  D340  0624  003120 | STG  r5,#SPILL33(,r13,25408)
003E46  E320  D270  0624  003120 | STG  r2,#SPILL7(,r13,25200)
003E4C  E350  D8FD  0571  003120 | LAY  r5,_temp9(,r13,22781)
003E52  E300  D368  0604  003120 | LG   r0,#SPILL38(,r13,25448)
003E58  E340  D308  0624  003120 | STG  r4,#SPILL26(,r13,25352)
003E5E  E310  D4B4  0271  003119 | LAY  r1,LINE(,r13,9396)
003E64  E300  D8FC  0550  003120 | STY  r0,_temp9(,r13,22780)
003E6A  E300  D148  0214  003120 | LGF  r0,a1:d8520:l4(,r13,8520)
003E70  D278  1000  4D33  003119 | MVC  LINE(121,r1,0),REPT_INIT(r4,3379)
003E76  4110  E00C003120 | LA   r1,_shadow21(,r14,12)
003E7A  E3E0  D8FC  0571  003120 | LAY  r14,_temp9(,r13,22780)
003E80  DE03  E000  1000  003120 | ED   _temp9(4,r14,0),_shadow21(r1,0)
003E86  B914  00E0003120 | LGFR r14,r0
003E8A  E300  D368  0604  003120 | LG   r0,#SPILL38(,r13,25448)
003E90  4110  E003003120 | LA   r1,#AddressShadow(,r14,3)
003E94  41F0  E00A003120 | LA   r15,#AddressShadow(,r14,10)
003E98  D202  1001  5000  003120 | MVC  _shadow21(3,r1,1),_temp9(r5,0)
003E9E  9240  E003003120 | MVI  _shadow21(r14,3),64
003EA2  E310  DF10  0158  003120 | LY   r1,a1:d7952:l4(,r13,7952)
003EA8  E300  D984  0550  003120 | STY  r0,_temp8(,r13,22916)
003EAE  E350  D984  0571  003120 | LAY  r5,_temp8(,r13,22916)
003EB4  4120  E017003120 | LA   r2,#AddressShadow(,r14,23)
003EB8  4110  100E003120 | LA   r1,_shadow21(,r1,14)
003EBC  DE03  5000  1000  003120 | ED   _temp8(4,r5,0),_shadow21(r1,0)
003EC2  E310  D985  0571  003120 | LAY  r1,_temp8(,r13,22917)
003EC8  4140  E028003120 | LA   r4,#AddressShadow(,r14,40)
003ECC  D202  F001  1000  003120 | MVC  _shadow21(3,r15,1),_temp8(r1,0)
003ED2  9240  E00A003120 | MVI  _shadow21(r14,10),64
003ED6  E310  DF10  0158  003120 | LY   r1,a1:d7952:l4(,r13,7952)
003EDC  E3F0  D974  0571  003120 | LAY  r15,_temp19(,r13,22900)

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Marco Gianfranco Indaco

Best wishes, and thanks for all your help, support and patience.

Marco Indaco

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

Re: EPSPT vs. FIXCAT

2012-05-16 Thread Jürgen Kehr


Hi Ant,

in theory that's possible, but it would be very uncomfortable to process 
more than a few PSP bucket files in such way. I'm looking for a solution 
where I can automate this process, for example to identify any update 
change in the PSP bucket files.



Am 16.05.2012 08:48, schrieb Anthony Thompson:

Can't you save the web page displaying the PSP bucket as a text file?


--
Freundliche Gruesse / Kind regards

*Dipl. Math. Juergen Kehr *
IT Schulung  Beratung / IT Education + Consulting
Elfbuchenstrasse 10
34317 Habichtswald
Germany

Tel. +49-5606-5337408
Fax +49-3222-9341387
Mobil +49-172-5129389
mailto:kehrjuer...@t-online.de
mailto:kehrjuer...@googlemail.com



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

Re: Syslog missing

W dniu 2012-05-15 20:33, Mark Zelden pisze:

What's wrong???

User error? :-)Did you change the SYSID or anything like that?
When you use the LOG command do you see an ISPF short message
error?

Try SYSID ? and see what it says.
Then SYSID with no operands.

1. SYSID

SYSID *was changed* recently.

The command SYSID ? shows:

JES SYSIDS=(NEW1),OLD1

and in the command line there appears text SYSID NEW1

Remarks:
Expected output from SYSID ? is JES SYSIDS=(NEW1) (tested on other systems)
I issued SYSID NEW1 - no effect
I issued SYSID OLD1 - and could not enter LOG (no msg)
I issued SYSID WRNG - and could not enter LOG (no msg)
MAS panel shows:
OLD1 DRAINED,P
NEW1 ACTIVE
(system is not sysplexed, PLEXCFG=MONOPLEX)

2. SYSLOG - OPERLOG
My log default is SYSLOG, previously I had OPERLOG only if Operlog is
active on your system.
I enter syslog by typing LOG or LOG S.
WHen I type LOG O I get the following message:
ISF036I NO RECORDS TO DISPLAY

3. LOG content
Real syslog content is accessible under ST, entry SYSLOG +MASTER+
LOG panel always show last few messages from last live - it contains
information since previous IPL to SHUTDOWN. No current information.

--
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.

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.

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

Re: z114/z196 LPAR Activation List

W dniu 2012-05-16 02:19, Kent Ramsay pisze:

Hi,

A customer recently installed a z114. When a Power-on Reset is done,
the LPAR's specified in the Partition Activation List are not
activated. This facility was working on the replaced z9. Has anyone
seen a similar occurrence? Thanks.

I had similar problems when:
a) no memory was available for the LPARS. In the activation profiles
there were more memory assigned than available.

b) LPAR id duplicate (I'm not sure about it).
c) Crypto Usage Domain duplicate.

In every case I conclued problem nature from the messages.
What messages do you see?
--
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

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
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.

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

Re: Syslog missing

R. Skorupka wrote:

I just noticed that syslog is dead.

Hmm, I have gone with this thread to see, but, Ok, can you perhaps explore 
these other options? (if already discussed, I may have missed it, sorry) :


Did you checked your ISFPRMxx member? Or drop those exits you mentioned earlier.

Is it only you who is having this problem? If you create a new TSO id, is the 
problem still there? If not, then something is wrong with your profile dataset? 
Perhaps if you could rename your profile dataset and logon again (with a new 
profile dataset) to see SYSLOG? [1]

Alternatively, issue WHO to see how you are defined to SDSF. Check your FILTER, 
OPTIONS, etc. for any settings?
 
Check RACF definitions in SDSF class if something has changed.

SYSID *was changed* recently.

Where? No, I'm serious, Where (parmlib, command, exit) was it changed?

Groete / Greetings
Elardus Engelbrecht

[ 1 ] - I have seen strange errors in TSO / ISPF which were resolved sometime 
by re-allocating a new profile dataset.

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Richards, Robert B.

Frank,

All of your SORT children will now have to grow up. I count myself among 
them. Sir, you spoiled us!

You are, most definitely, leaving the SORT world a better place than you found 
it; a very fine testament to your career.

Please do check back in with us from time to time. I'll smile when I see your 
name and remember that we had it great once! :-)  

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Frank Yaeger
Sent: Tuesday, May 15, 2012 9:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

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

Re: Syslog missing (solution???)

http://www-01.ibm.com/support/docview.wss?uid=isg1OA39170

It's quite fresh.

BTW: very interesting problem for lawyers:
I changed sysid to meet SCRT requirements, otherwise SCRT cannot prepare
correct report for the LPAR running this system.

I can say I cannot change sysid due to error in IBM code.
Catch 22? vbg

--
Radoslaw Skorupka
Lodz, Poland

W dniu 2012-05-16 11:14, R.S. pisze:

W dniu 2012-05-15 20:33, Mark Zelden pisze:

What's wrong???

User error? :-) Did you change the SYSID or anything like that?
When you use the LOG command do you see an ISPF short message
error?

Try SYSID ? and see what it says.
Then SYSID with no operands.

1. SYSID

SYSID *was changed* recently.

The command SYSID ? shows:

JES SYSIDS=(NEW1),OLD1

and in the command line there appears text SYSID NEW1

--
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.

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

BRE Bank SA, 00-950 Warszawa,

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Alvaro Guirao Lopez

I've been also one of those who discovers in my begginings Frank Yaeger
helping us in our daily sorting problems.

A very very very THANK YOU

I Wish you the best of the retirements.

2012/5/16 Richards, Robert B. robert.richa...@opm.gov

 Frank,

 All of your SORT children will now have to grow up. I count myself among
 them. Sir, you spoiled us!

 You are, most definitely, leaving the SORT world a better place than you
 found it; a very fine testament to your career.

 Please do check back in with us from time to time. I'll smile when I see
 your name and remember that we had it great once! :-)

 Bob

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
 Behalf Of Frank Yaeger
 Sent: Tuesday, May 15, 2012 9:00 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Retiring after 43+ years with IBM

 Just a note to let everyone know I'll be retiring at the end
 of this month (5/31/2012).  I've been with IBM for 43+ years
 (plus a couple of summers in college) and I've enjoyed my
 career immensely.  I've especially enjoyed being able to
 help people use the DFSORT/ICETOOL functions I developed,
 over many years, in new and interesting ways.

 Once I retire, I won't be posting solutions any more since I
 won't have access to a mainframe to test them, and I don't
 like posting untested solutions.  I may lurk a bit or I may
 not.

 I'm looking forward to retirement, but I'll also miss this
 list.  I'm happy to say that others on the DFSORT Team will
 continue to contribute.

 Thanks to everyone for giving me the chance to earn a living
 all these years doing something that was a lot of fun for
 me.

 Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

 Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
 Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

  = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

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




-- 
Un saludo.
Álvaro Guirao

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

Re: Syslog missing (solution???)

R.Skorupka wrote:

http://www-01.ibm.com/support/docview.wss?uid=isg1OA39170

Interesting that SDSF suffers from JES2 handling of $QSE control block. Hmmm...

It's quite fresh.

Absolutely! Despite its age, it is now 'CLOSED PER'. 
... and you have to carry out the local fix, which you already told us in this 
thread...

BTW: very interesting problem for lawyers:

Shhh, you will make them rich at your retirement's expense ;-D

I changed sysid to meet SCRT requirements, otherwise SCRT cannot prepare 
correct report for the LPAR running this system.

Yuck! Could you be kind to elaborate on this required change? I'm also using 
this SCRT toy every month.

Groete / Greetings
Elardus Engelbrecht

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

Servicelink, ETR and SR

2012-05-16 Thread Barbara Nitz

Given that IBM took away ETR yesterday and has by now forced SR upon the 
mainframe world - do Americans coming from servicelink also have to login again 
to get to their ETRs??? Or is this 'privilege' reserved for EMEA?

Until ETR was taken away (yesterday morning our time) no extra login from 
Servicelink was required, SR was reachable using the normal servicelink login. 
I consider this an error and have opened a ticket.

Barbara Nitz

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

Re: Syslog missing (now: SCRT)

W dniu 2012-05-16 12:42, Elardus Engelbrecht pisze:
[...]

I changed sysid to meet SCRT requirements, otherwise SCRT cannot
prepare correct report for the LPAR running this system.

Yuck! Could you be kind to elaborate on this required change? I'm
also using this SCRT toy every month.

SCRT does require all systems to have uniques SYSID. This requirement is
described in SCRT manual.

SCRT is REALLY BAD product, I know several cases where it gives false
results even if you fulfill all the requirement.

SCRT does like: unique SYSIDs, *stable* SYSIDS (not changed during the
reporting period).
SCRT does not like: changing SYSIDs, SMF records out of the scope (i.e.
from previous month) - I mean valid records PLUS older ones.
SCRT hates: non-unique SYSIDs, or SMF70 with no SMF89 or vice versa - I
mean scenario: you IPL system for 15 minutes, then you shut it down.
It's unusual, but IMHO legal to start z/OS for short period of time.

BTW: the requirement of uniques SYSIDs is simply STUPID. There is
identifier which is really unique: LPAR name. From the other hand there
are cases when you could need imple PiT copy, a CLONE of you z/OS
system. You can clone everything except the SYSID. Reason: SCRT.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Robert Prins


On 2012-05-16 07:26, Elardus Engelbrecht wrote:

Robert Prins wrote:


Can anyone skilled in the art tell me why a compiler that probably dates back to the late 
1970'ies or early 1980'ies generates the following short and sweet code for a PL/I 
BY NAME assignment, while the not completely new (but still fairly recent) 
version of Enterprise PL/I (V3R9) generates the very, very, very long-winded code below 
it?


I'm not skilled in this art, but is your Enterprise PL/I (v3r9) also using 
Language Environment or not?


Yes, it is.


Then again, I always thought that the fastest instructions are those ones that 
are never executed...


Those instructions don't need to be optimized... :-)


Exactly!

Robert
--
Robert AH Prins
robert(a)prino(d)org

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

Re: Servicelink, ETR and SR

2012-05-16 Thread van der Grijn, Bart (B)

Same here (US based).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barbara Nitz
Sent: Wednesday, May 16, 2012 6:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Servicelink, ETR and SR

Given that IBM took away ETR yesterday and has by now forced SR upon the 
mainframe world - do Americans coming from servicelink also have to login again 
to get to their ETRs??? Or is this 'privilege' reserved for EMEA?

Until ETR was taken away (yesterday morning our time) no extra login from 
Servicelink was required, SR was reachable using the normal servicelink login. 
I consider this an error and have opened a ticket.

Barbara Nitz

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

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Stocker, Herman

Frank,
Enjoy your time off, you have helped so many people on this list.  Thank you.


Regards,
Herman Stocker

It is impossible to make anything foolproof, because fools are so ingenious.
 -- Robert Heinlein
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Frank Yaeger
Sent: Tuesday, May 15, 2012 9:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end of this month 
(5/31/2012).  I've been with IBM for 43+ years (plus a couple of summers in 
college) and I've enjoyed my career immensely.  I've especially enjoyed being 
able to help people use the DFSORT/ICETOOL functions I developed, over many 
years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I won't have access 
to a mainframe to test them, and I don't like posting untested solutions.  I 
may lurk a bit or I may not.

I'm looking forward to retirement, but I'll also miss this list.  I'm happy to 
say that others on the DFSORT Team will continue to contribute.

Thanks to everyone for giving me the chance to earn a living all these years 
doing something that was a lot of fun for me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

 ---

The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

 ---

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

Re: Syslog missing (now: SCRT)

R Skorupka wrote:

SCRT does require all systems to have uniques SYSID. This requirement is 
described in SCRT manual.

Oh yes, I now rereaded that part. Thanks for the reminder.

SCRT is REALLY BAD product, I know several cases where it gives false results 
even if you fulfill all the requirement.

Really bad? To add to your pain, look up the new paragraph 'Machine 
replacements and machine software model upgrades' and come back...

SCRT does not like: changing SYSIDs, SMF records out of the scope (i.e. from 
previous month) - I mean valid records PLUS older ones.

I hate it to add *NONE to each software product you're not using... but that is 
only me and my lazy typing... [1]  :-/

BTW: the requirement of uniques SYSIDs is simply STUPID. There is identifier 
which is really unique: LPAR name. From the other hand there are cases when 
you could need imple PiT copy, a CLONE of you z/OS system. You can clone 
everything except the SYSID. Reason: SCRT.

There must be a reason beside SCRT, but I'm too low in the food chain to 
challenge/question it... :-)

Groete / Greetings
Elardus Engelbrecht

[1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking 
something ...

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

Re: ### of GDG Entries

In a6b9336cdb62bb46b9f8708e686a7ea00e924b4...@nrhmms8p02.uicnrh.dom,
on 05/14/2012
   at 10:34 AM, McKown, John john.mck...@healthmarkets.com said:

About as smoothly as a Baja race.

I don't know anything about Baja races, but I assume from your comment
that they're painful.

I still have scars.

I missed the initial release of DF/EF, and after reading the feedback
I was quite happy that I'd missed it, even though I normally like to
be an early adopter.
 
-- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: CSVEDIT using COBOL

In 4fb145d3.7090...@valley.net, on 05/14/2012
   at 01:50 PM, Gerhard Postpischil gerh...@valley.net said:

However, for INTRDR the class is ignored. 

No; it becomes the default MSGCLASS.
 
-- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Is having an OMVS segment on a userid with RACF SPECIAL an issue?

In 4fb1f921.8020...@bremultibank.com.pl, on 05/15/2012
   at 08:35 AM, R.S. r.skoru...@bremultibank.com.pl said:

IMHO the are two secure choices:

1. NOOMVS for SPECIAL

2. UID(0) for SPECIAL.

Boggle!
 
-- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Syslog missing (now: SCRT)

W dniu 2012-05-16 13:42, Elardus Engelbrecht pisze:

[1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking
something ...

But you can split the job stream. I moved DD * content to separate
members and DO NOT change them. Also the JCL itself is (almost) not
changed. The only change is to replace object code.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Steve Conway

Best of luck to you in your retirement, Frank.
Thank you for all your help over the years. 
You've made your mark on our world, and a person can be content with that 
knowledge.


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Frank Yaeger yae...@us.ibm.com
To: IBM-MAIN@bama.ua.edu
Date:   05/15/2012 09:01 PM
Subject:Retiring after 43+ years with IBM
Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu



Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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


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

Z/OS TELNET SERVER SCANINTERVAL TIMEMARK

2012-05-16 Thread Bernard Coeytaux

Hello,
Is the timemark packet send to the particulary client tn3270 port or is it just 
a ping to the client ipaddr ?
I other words if we have a server with many sessions (like websphere with 
HATS), is the timemark sent to every client hats-hod client or is it just the 
presence of the server that is checked ?

Thanks and regards
Bernard Coeytaux

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Steve Comstock


On 5/16/2012 1:26 AM, Elardus Engelbrecht wrote:

Robert Prins wrote:


Can anyone skilled in the art tell me why a compiler that probably dates
back

to the late 1970'ies or early 1980'ies generates the following short and sweet
code for a PL/I BY NAME assignment, while the not completely new (but still
fairly recent) version of Enterprise PL/I (V3R9) generates the very, very, very
long-winded code below it?


I'm not skilled in this art, but is your Enterprise PL/I (v3r9) also using 
Language Environment or not?


He has no choice on this: all the new compilers _must_ use LE.





Then again, I always thought that the fastest instructions are those ones that 
are never executed...


Those instructions don't need to be optimized... :-)

Groete / Greetings
Elardus Engelbrecht


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Syslog missing (now: SCRT)

R Skorupka wrote:

 [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking 
 something ...

But you can split the job stream. I moved DD * content to separate members and 
DO NOT change them. Also the JCL itself is (almost) not changed. The only 
change is to replace object code.

Yes, you can do that good splitting work, but it is still a PITA to check all 
software (when using a new release of SCRT) to ensure you don't skip one. One 
can copy/sort all software numbers and then do a compare/editing in that DD *. 

Question for lazy ones: Is it possible [in the future] to feed SCRT a list of 
all IFAPRDxx members for all your LPARs, so no manual editing is needed? Or 
feed a list of RACF profiles in a new RACF class for all products used on what 
LPAR/machine? Then SCRT can just scan that class and apply it to your SMF recs?

Groete / Greetings
Elardus Engelbrecht

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Rob Schramm

Frank,

Best wishes for your retirement.

Rob Schramm
Senior Systems Consultant
Imperium Group



On Wed, May 16, 2012 at 7:58 AM, Steve Conway
steve_con...@ao.uscourts.gov wrote:
 Best of luck to you in your retirement, Frank.
 Thank you for all your help over the years.
 You've made your mark on our world, and a person can be content with that
 knowledge.


 Cheers,,,Steve

 Steven F. Conway, CISSP
 LA Systems
 z/OS Systems Support
 Phone: 703.295.1926
 steve_con...@ao.uscourts.gov



 From:   Frank Yaeger yae...@us.ibm.com
 To:     IBM-MAIN@bama.ua.edu
 Date:   05/15/2012 09:01 PM
 Subject:        Retiring after 43+ years with IBM
 Sent by:        IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu



 Just a note to let everyone know I'll be retiring at the end
 of this month (5/31/2012).  I've been with IBM for 43+ years
 (plus a couple of summers in college) and I've enjoyed my
 career immensely.  I've especially enjoyed being able to
 help people use the DFSORT/ICETOOL functions I developed,
 over many years, in new and interesting ways.

 Once I retire, I won't be posting solutions any more since I
 won't have access to a mainframe to test them, and I don't
 like posting untested solutions.  I may lurk a bit or I may
 not.

 I'm looking forward to retirement, but I'll also miss this
 list.  I'm happy to say that others on the DFSORT Team will
 continue to contribute.

 Thanks to everyone for giving me the chance to earn a living
 all these years doing something that was a lot of fun for
 me.

 Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

 Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
 Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

  = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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


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

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Kerneels


Frank,

Enjoy your retirement...you deserve it..

http://www.youtube.com/watch?v=rGIwZccbRI0feature=related

Anton

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Paul Gilmartin

On Wed, 16 May 2012 06:41:27 -0600, Steve Comstock wrote:

He has no choice on this: all the new compilers _must_ use LE.

Even Metal C?

-- gil

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Lloyd Fuller

Metal C does NOT use LE.  And, of course, with HLASM you have the choice to not 
use LE or to make your program LE compatible.

Lloyd



- Original Message 
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@bama.ua.edu
Sent: Wed, May 16, 2012 9:12:24 AM
Subject: Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

On Wed, 16 May 2012 06:41:27 -0600, Steve Comstock wrote:

He has no choice on this: all the new compilers _must_ use LE.

Even Metal C?

-- gil

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

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

Re: EPSPT vs. FIXCAT

2012-05-16 Thread Kurt Quackenbush


If you look on PSP bucket Upgrade CICSTS42, Subset HCI6700 you'll find
several PTFs in the service recommendation section. Because FIXCATs are
not (yet) available for CICS, you will not find any FIXCAT infos for
these PTFs.


FIXCAT HOLDs are indeed available for CICS.  In the PSP bucket you 
reference I see this latest entry:


  12/04/30 PM59329  UK78038  1000 HIPER CICS TS VER.4.2 JVM HIGH

In addition in the latest HOLDDATA file I see the following 
corresponding ++HOLD statement:


++HOLD(HCI6700) FIXCAT FMID(HCI6700) REASON(AM59329) RESOLVER(UK78038)
 CATEGORY(IBM.ProductInstall-RequiredService)
 DATE(12118).

What am I missing?  The IBM.ProductInstall-RequiredService fix category 
is a generic category that is applicable to all products, and identifies 
fixes specified in the service recommendation section of PSP buckets.


The HOLDDATA file containing FIXCATs is delivered with PTF service 
orders or can be found here:

ftp://service.boulder.ibm.com/s390/holddata/full.txt

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Steve Dover

Frank,  
You will be missed.  Congrats and good luck, good health

Steve

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Kirk Talman

Ad multos annos!  My your retirement be as fruitful for you as your 
presence here has been for those who listened and learned.

Seriously jealous of all who have the option of retiring.  After 5 
decades, the enthusiasm wanes.

peace

IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 05/15/2012 
09:00:05 PM:

 From: Frank Yaeger yae...@us.ibm.com
 
 Just a note to let everyone know I'll be retiring at the end
 of this month (5/31/2012).  I've been with IBM for 43+ years
 (plus a couple of summers in college) and I've enjoyed my
 career immensely.  I've especially enjoyed being able to
 help people use the DFSORT/ICETOOL functions I developed,
 over many years, in new and interesting ways.
 
 Once I retire, I won't be posting solutions any more since I
 won't have access to a mainframe to test them, and I don't
 like posting untested solutions.  I may lurk a bit or I may
 not.
 
 I'm looking forward to retirement, but I'll also miss this
 list.  I'm happy to say that others on the DFSORT Team will
 continue to contribute.
 
 Thanks to everyone for giving me the chance to earn a living
 all these years doing something that was a lot of fun for
 me.
 
 Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!
 
 Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
 Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
 
  = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

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

Re: Z/OS TELNET SERVER SCANINTERVAL TIMEMARK

2012-05-16 Thread Lizette Koehler

If you have not done so, you may also wish to join the TCPIP newsgroup 

For IBMTCP-L subscribe / signoff / archive access instructions, send email
to lists...@vm.marist.edu with the message: INFO IBMTCP-L


Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of
 Bernard Coeytaux
 Sent: Wednesday, May 16, 2012 5:33 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Z/OS TELNET SERVER SCANINTERVAL TIMEMARK
 
 Hello,
 Is the timemark packet send to the particulary client tn3270 port or is it
just a ping to
 the client ipaddr ?
 I other words if we have a server with many sessions (like websphere with
HATS), is
 the timemark sent to every client hats-hod client or is it just the
presence of the
 server that is checked ?
 
 Thanks and regards
 Bernard Coeytaux
 

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

Re: Syslog missing

2012-05-16 Thread Mark Zelden

On Wed, 16 May 2012 11:14:36 +0200, R.S. r.skoru...@bremultibank.com.pl wrote:

W dniu 2012-05-15 20:33, Mark Zelden pisze:
 What's wrong???



 User error? :-)Did you change the SYSID or anything like that?
 When you use the LOG command do you see an ISPF short message
 error?

 Try SYSID ?  and see what it says.
 Then  SYSID with no operands.

1. SYSID

SYSID *was changed* recently.

The command SYSID ? shows:

JES SYSIDS=(NEW1),OLD1

and in the command line there appears text SYSID NEW1

Remarks:
Expected output from SYSID ? is JES SYSIDS=(NEW1) (tested on other systems)
I issued SYSID NEW1 - no effect
I issued SYSID OLD1 - and could not enter LOG (no msg)
I issued SYSID WRNG - and could not enter LOG (no msg)
MAS panel shows:
  OLD1 DRAINED,P
  NEW1 ACTIVE
(system is not sysplexed, PLEXCFG=MONOPLEX)


2. SYSLOG - OPERLOG
My log default is SYSLOG, previously I had OPERLOG only if Operlog is
active on your system.
I enter syslog by typing LOG or LOG S.
WHen I type LOG O I get the following message:
ISF036I NO RECORDS TO DISPLAY


3. LOG content
Real syslog content is accessible under ST, entry  SYSLOG +MASTER+
LOG panel always show last few messages from last live  - it contains
information since previous IPL to SHUTDOWN. No current information.



Running out of ideas here.  :-)

1) Delete your ISFPROF from your userid.ISPPROF data set and try again.  If this
fixes the problem, I think you've run into a bug that should be reported to IBM
if you want to spend the time doing so.

2)  What is your syslog output class?  Is there any of it left in the spool 
that could
be from the old SYSID?  If so, delete it all.   Do a WRITELOG command and
then try again.   

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Syslog missing (now: SCRT)

2012-05-16 Thread Hal Merritt

I moved the object code out of the job stream into a parmlib like PDS. My job 
scheduler was taking exception to the object code being in stream.   

The JCL changes have been uncommon and not hard to hand jive. 
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Wednesday, May 16, 2012 6:57 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Syslog missing (now: SCRT)

W dniu 2012-05-16 13:42, Elardus Engelbrecht pisze:

 [1] - You just can't go on a C ALL '= ' '=*NONE' spree without breaking 
 something ...

But you can split the job stream. I moved DD * content to separate members and 
DO NOT change them. Also the JCL itself is (almost) not changed. The only 
change is to replace object code.
--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: EPSPT vs. FIXCAT

2012-05-16 Thread Mark Zelden

On Wed, 16 May 2012 07:27:22 +0200, Jürgen Kehr kehrjuer...@t-online.de wrote:

Because FIXCATs are
not (yet) available for CICS, you will not find any FIXCAT infos for
these PTFs.

That is not correct.  Are you sure you are downloading the full holddata file?
The other ones don't have FIXCAT.  That is true for z/OS also.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Steve Comstock


On 5/16/2012 7:11 AM, Paul Gilmartin wrote:

On Wed, 16 May 2012 06:41:27 -0600, Steve Comstock wrote:


He has no choice on this: all the new compilers _must_ use LE.


Even Metal C?

-- gil


Well, I knew someone would raise that exception. No,
Metal C does not use LE. Not sure if SP C (Systems
Programmer C) is still around and it would be an
exception too.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Syslog missing (solution???)

2012-05-16 Thread Mark Zelden

On Wed, 16 May 2012 12:19:55 +0200, R.S. r.skoru...@bremultibank.com.pl wrote:

http://www-01.ibm.com/support/docview.wss?uid=isg1OA39170

It's quite fresh.


 MAS panel shows:
 OLD1 DRAINED,P
 NEW1 ACTIVE
 (system is not sysplexed, PLEXCFG=MONOPLEX)

Based on you mas display, that sounds like a match.   If you aren't planning
on going back to OLD1, then the other local fix is to remove OLD1 from
your JES2 parms and IPL (all systems warmstart of JES2 - so you could just
shut everything down and restart JES2 also).   You will be prompted with a
question asking if you want to remove the OLD1 SYSID.  Do so and I assume
your problem will be fixed.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Servicelink, ETR and SR

2012-05-16 Thread Wissink, Brad [ITSYS]

I have to login in again to get to SR.  

Brad Wissink
Information Technology Services
Iowa State University
515-294-3088
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barbara Nitz
Sent: Wednesday, May 16, 2012 5:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Servicelink, ETR and SR

Given that IBM took away ETR yesterday and has by now forced SR upon the 
mainframe world - do Americans coming from servicelink also have to login again 
to get to their ETRs??? Or is this 'privilege' reserved for EMEA?

Until ETR was taken away (yesterday morning our time) no extra login from 
Servicelink was required, SR was reachable using the normal servicelink login. 
I consider this an error and have opened a ticket.

Barbara Nitz

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

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

Re: EPSPT vs. FIXCAT

2012-05-16 Thread Jürgen Kehr


Hi Mark,

so please tell me which category is used for CICS? When I look through 
the catalog at 
http://www-03.ibm.com/systems/z/os/zos/smpe/fixcategory.html I could not 
find any CICS category, there are some for z/OS, for DB2, for IMS etc. 
but where are the CICS categories?


Am 16.05.2012 15:54, schrieb Mark Zelden:

That is not correct.  Are you sure you are downloading the full holddata file?
The other ones don't have FIXCAT.  That is true for z/OS also.


--
Freundliche Gruesse / Kind regards

*Dipl. Math. Juergen Kehr *
IT Schulung  Beratung / IT Education + Consulting
Elfbuchenstrasse 10
34317 Habichtswald
Germany

Tel. +49-5606-5337408
Fax +49-3222-9341387
Mobil +49-172-5129389
mailto:kehrjuer...@t-online.de
mailto:kehrjuer...@googlemail.com



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

Re: Servicelink, ETR and SR

2012-05-16 Thread Skip Robinson

I've been using SR exclusively for some time. Until now, if I selected the 
SR option on the ServiceLink main menu, I would be taken straight to the 
SR main page. I just now discovered the new behavior described. I also see 
this. If it was there before, I didn't notice.

You must sign into this application, even if you have already signed into 
IBM on the masthead.

.
.
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:   Wissink, Brad [ITSYS] bjwi...@iastate.edu
To: IBM-MAIN@bama.ua.edu
Date:   05/16/2012 07:01 AM
Subject:Re: Servicelink, ETR and SR
Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu



I have to login in again to get to SR. 

Brad Wissink
Information Technology Services
Iowa State University
515-294-3088
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf Of Barbara Nitz
Sent: Wednesday, May 16, 2012 5:47 AM
To: IBM-MAIN@bama.ua.edu
Subject: Servicelink, ETR and SR

Given that IBM took away ETR yesterday and has by now forced SR upon the 
mainframe world - do Americans coming from servicelink also have to login 
again to get to their ETRs??? Or is this 'privilege' reserved for EMEA?

Until ETR was taken away (yesterday morning our time) no extra login from 
Servicelink was required, SR was reachable using the normal servicelink 
login. I consider this an error and have opened a ticket.

Barbara Nitz


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

Re: EPSPT vs. FIXCAT

2012-05-16 Thread Jürgen Kehr


Hi Kurt,

thanks, that is the information I wasn't aware of, the fact that for 
CICS there isn't a special category like for IMS or DB2 and that these 
PTFs are all together in this generic category. So all PTFs from the 
former PSP extract files are now in any category either in a specific or 
in such a generic category?


One additional question: Are the other informations from the PSP buckets 
(Installation Information, Documentation Changes, General Information 
etc.) somewhere available as downloadable txt files?



Am 16.05.2012 15:35, schrieb Kurt Quackenbush:
The IBM.ProductInstall-RequiredService fix category is a generic 
category that is applicable to all products, and identifies fixes 
specified in the service recommendation section of PSP buckets.


--
Freundliche Gruesse / Kind regards

*Dipl. Math. Juergen Kehr *
IT Schulung  Beratung / IT Education + Consulting
Elfbuchenstrasse 10
34317 Habichtswald
Germany

Tel. +49-5606-5337408
Fax +49-3222-9341387
Mobil +49-172-5129389
mailto:kehrjuer...@t-online.de
mailto:kehrjuer...@googlemail.com



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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Paul Gilmartin

On Wed, 16 May 2012 07:55:48 -0600, Steve Comstock wrote:

Well, I knew someone would raise that exception. No,
Metal C does not use LE. Not sure if SP C (Systems
Programmer C) is still around and it would be an
exception too.
 
I believe it's been discussed in these fora that C and PL/I
share an optimizer/code generator.  I hope this includes
Metal C.  It's a long leap of logic, but that might weaken the
argument for LE entanglement.  Is MOVE, BY NAME
plausibly dependent on LE?

-- gil

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Robert Prins


David,

On 2012-05-16 08:23, David Crayford wrote:
 Robert,

 I'm no expert but I have read that newer hardware models (Z10 and above) are
 essentially RISC processors that run complex instructions in millicode. In the

I may be wrong, but I think the z196 is the first OOO machine and Enterprise PL/I V3R9 pre-dates it 
by two years.


 case of a MVC instruction it would have to do that in a loop which would 
require
 branching, the enemy of pipelined exeuction units. It's also possible to run
 simple instructions
 in parallel. It's plausible an MVC instruction can be executed more 
efficiently
 as a sequence of LG/STG instructions.

Given that moves are the most executed instructions, at least on x86, (see, among many others 
www.ijpg.org/index.php/IJACSci/article/download/118/29) and I have little doubt that the same 
holds true for about any other architecture and that there is special x86 circuitry to optimize MOVS 
instructions, it would be highly surprising if IBM did not make MVC as fast as possible, millicoded 
or not.


 The OOO decode units do this for you with instruction cracking on a z196, it
 seems that on a z10 the optimizer is doing the same thing.

Possibly, but that does not explain the 10 superfluous reloads of r1.

 See this document - page 21
 
http://www-01.ibm.com/software/htp/tpf/tpfug/tgf11/How_do_you_do_when_youre_a_z196_CPU.pdf

 Optimizers create arcane code. It's almost impossible to verify without
 understanding the secret sauce. A lot of the code the optimizers spit out is
 intractable,

I don't know much about z/OS assembler, but at least I sort of managed to understand the code 
generated by the OS PL/I compiler. The code generated by Enterprise PL/I is completely unreadable, 
even some (or more than some) on this list might have trouble figuring out why it does what it does.


 and it's almost a paradox that a longer code path produces faster code.

 If you don't like it you can always compile at a different ARCH() level and 
ask
 IBM.

Going back to ARCH(5) doesn't produce anything that seems much shorter, still the ridiculous 
reloading of the same register, and oodles and oodles instructions which would run and take time on 
a definitely not-OOO CPU:


003A58  E300  8238  0014  003119 | LGF   r0,LINE_PTR(,r8,568)
003A5E  4110  E00C003119 | LAr1,_shadow21(,r14,12)
003A62  B914  00E0003119 | LGFR  r14,r0
003A66  D278  B38E  6D33  003118 | MVC   LINE(121,r11,910),REPT_INIT(r6,3379)
003A6C  E3B0  DC20  0004  003119 | LGr11,#SPILL17(,r13,3104)
003A72  50B0  D25C003119 | STr11,_temp9(,r13,604)
003A76  DE03  D25C  1000  003119 | ED_temp9(4,r13,604),_shadow21(r1,0)
003A7C  4110  E003003119 | LAr1,#AddressShadow(,r14,3)
003A80  41F0  E00A003119 | LAr15,#AddressShadow(,r14,10)
003A84  D202  1001  D25D  003119 | MVC   _shadow21(3,r1,1),_temp9(r13,605)
003A8A  9240  E003003119 | MVI   _shadow21(r14,3),64
003A8E  5810  8000003119 | L r1,REPT_PTR(,r8,0)
003A92  50B0  D2E4003119 | STr11,_temp8(,r13,740)
003A96  41B0  E017003119 | LAr11,#AddressShadow(,r14,23)
003A9A  4110  100E003119 | LAr1,_shadow21(,r1,14)
003A9E  DE03  D2E4  1000  003119 | ED_temp8(4,r13,740),_shadow21(r1,0)
003AA4  D202  F001  D2E5  003119 | MVC   _shadow21(3,r15,1),_temp8(r13,741)
003AAA  9240  E00A003119 | MVI   _shadow21(r14,10),64
003AAE  5810  8000003119 | L r1,REPT_PTR(,r8,0)
003AB2  E3F0  DB98  0004  003119 | LGr15,#SPILL0(,r13,2968)
003AB8  D202  E011  1010  003119 | MVC   _shadow21(3,r14,17),_shadow21(r1,16)
003ABE  5810  8000003119 | L r1,REPT_PTR(,r8,0)
003AC2  D206  D2D4  F4A4  003119 | MVC   _temp19(7,r13,724),' ..'(r15,1188)
003AC8  D203  D26C  1013  003119 | MVC   _temp15(4,r13,620),_shadow18(r1,19)
003ACE  4110  D26C003119 | LAr1,_temp15(,r13,620)
003AD2  D202  D24C  1001  003119 | MVC   _temp11(3,r13,588),_shadow12(r1,1)
003AD8  4110  D24C003119 | LAr1,_temp11(,r13,588)
003ADC  DE06  D2D4  1000  003119 | ED_temp19(7,r13,724),_temp11(r1,0)
003AE2  D205  B000  D2D5  003119 | MVC   _shadow21(6,r11,0),_temp19(r13,725)
003AE8  5810  8000003119 | L r1,REPT_PTR(,r8,0)
003AEC  D206  D2CC  F4A4  003119 | MVC   _temp21(7,r13,716),' ..'(r15,1188)
003AF2  D202  D249  101B  003119 | MVC   _temp18(3,r13,585),_shadow12(r1,27)
003AF8  D202  D246  D249  003119 | MVC   _temp20(3,r13,582),_temp18(r13,585)
003AFE  4110  E028003119 | LAr1,#AddressShadow(,r14,40)
003B02  E300  D246  0090  003119 | LLGC  r0,a1:d582:l1(,r13,582)
003B08  E300  3114  0080  003119 | NGr0,=X' 000F'
003B0E  41B0  D246003119 | LAr11,_temp20(,r13,582)
003B12  4200  D246003119 | STC   r0,a1:d582:l1(,r13,582)
003B16  DE06  D2CC  B000  003119 | ED_temp21(7,r13,716),_temp20(r11,0)
003B1C  D204  1000  D2CE  003119 | MVC   _shadow21(5,r1,0),_temp21(r13,718)
003B22  5810  8000003119 | L

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Robert Prins


On 2012-05-16 14:59, Paul Gilmartin wrote:

On Wed, 16 May 2012 07:55:48 -0600, Steve Comstock wrote:


Well, I knew someone would raise that exception. No,
Metal C does not use LE. Not sure if SP C (Systems
Programmer C) is still around and it would be an
exception too.


I believe it's been discussed in these fora that C and PL/I
share an optimizer/code generator.  I hope this includes
Metal C.  It's a long leap of logic, but that might weaken the
argument for LE entanglement.  Is MOVE, BY NAME
plausibly dependent on LE?


For PL/I is is most definitely not, it's just a shortcut for lazy people and I've worked at sites 
that explicitly forbade its use, considering it just as bad as a SELECT * in SQL.


Robert
--
Robert AH Prins
robert(a)prino(d)org

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

RES: Retiring after 43+ years with IBM

2012-05-16 Thread ITURIEL DO NASCIMENTO NETO

Mr. Yaeger,

I want to say that DFSORT is very admired in mainframe environment because of 
you.
Good luck in your retirement and enjoy your family.


Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4254 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-2177 R: 42177 3-1402
Fax: +55 11 4197-2814

-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de 
Frank Yaeger
Enviada em: terça-feira, 15 de maio de 2012 22:00
Para: IBM-MAIN@bama.ua.edu
Assunto: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

AVISO LEGAL br...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICEbr...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Miklos Szigetvari

Hi

Do you have the chance to compare the speed of the two codes ?


 David,

 On 2012-05-16 08:23, David Crayford wrote:
   Robert,
  
   I'm no expert but I have read that newer hardware models (Z10 and
 above) are
   essentially RISC processors that run complex instructions in millicode.
 In the

 I may be wrong, but I think the z196 is the first OOO machine and
 Enterprise PL/I V3R9 pre-dates it
 by two years.

   case of a MVC instruction it would have to do that in a loop which
 would require
   branching, the enemy of pipelined exeuction units. It's also possible
 to run
   simple instructions
   in parallel. It's plausible an MVC instruction can be executed more
 efficiently
   as a sequence of LG/STG instructions.

 Given that moves are the most executed instructions, at least on x86,
 (see, among many others
 www.ijpg.org/index.php/IJACSci/article/download/118/29) and I have
 little doubt that the same
 holds true for about any other architecture and that there is special x86
 circuitry to optimize MOVS
 instructions, it would be highly surprising if IBM did not make MVC as
 fast as possible, millicoded
 or not.

   The OOO decode units do this for you with instruction cracking on a
 z196, it
   seems that on a z10 the optimizer is doing the same thing.

 Possibly, but that does not explain the 10 superfluous reloads of r1.

   See this document - page 21
   
 http://www-01.ibm.com/software/htp/tpf/tpfug/tgf11/How_do_you_do_when_youre_a_z196_CPU.pdf
  
   Optimizers create arcane code. It's almost impossible to verify without
   understanding the secret sauce. A lot of the code the optimizers spit
 out is
   intractable,

 I don't know much about z/OS assembler, but at least I sort of managed to
 understand the code
 generated by the OS PL/I compiler. The code generated by Enterprise PL/I
 is completely unreadable,
 even some (or more than some) on this list might have trouble figuring out
 why it does what it does.

   and it's almost a paradox that a longer code path produces faster code.
  
   If you don't like it you can always compile at a different ARCH() level
 and ask
   IBM.

 Going back to ARCH(5) doesn't produce anything that seems much shorter,
 still the ridiculous
 reloading of the same register, and oodles and oodles instructions which
 would run and take time on
 a definitely not-OOO CPU:

 003A58  E300  8238  0014  003119 | LGF   r0,LINE_PTR(,r8,568)
 003A5E  4110  E00C003119 | LAr1,_shadow21(,r14,12)
 003A62  B914  00E0003119 | LGFR  r14,r0
 003A66  D278  B38E  6D33  003118 | MVC
 LINE(121,r11,910),REPT_INIT(r6,3379)
 003A6C  E3B0  DC20  0004  003119 | LGr11,#SPILL17(,r13,3104)
 003A72  50B0  D25C003119 | STr11,_temp9(,r13,604)
 003A76  DE03  D25C  1000  003119 | ED_temp9(4,r13,604),_shadow21(r1,0)
 003A7C  4110  E003003119 | LAr1,#AddressShadow(,r14,3)
 003A80  41F0  E00A003119 | LAr15,#AddressShadow(,r14,10)
 003A84  D202  1001  D25D  003119 | MVC   _shadow21(3,r1,1),_temp9(r13,605)
 003A8A  9240  E003003119 | MVI   _shadow21(r14,3),64
 003A8E  5810  8000003119 | L r1,REPT_PTR(,r8,0)
 003A92  50B0  D2E4003119 | STr11,_temp8(,r13,740)
 003A96  41B0  E017003119 | LAr11,#AddressShadow(,r14,23)
 003A9A  4110  100E003119 | LAr1,_shadow21(,r1,14)
 003A9E  DE03  D2E4  1000  003119 | ED_temp8(4,r13,740),_shadow21(r1,0)
 003AA4  D202  F001  D2E5  003119 | MVC
 _shadow21(3,r15,1),_temp8(r13,741)
 003AAA  9240  E00A003119 | MVI   _shadow21(r14,10),64
 003AAE  5810  8000003119 | L r1,REPT_PTR(,r8,0)
 003AB2  E3F0  DB98  0004  003119 | LGr15,#SPILL0(,r13,2968)
 003AB8  D202  E011  1010  003119 | MVC
 _shadow21(3,r14,17),_shadow21(r1,16)
 003ABE  5810  8000003119 | L r1,REPT_PTR(,r8,0)
 003AC2  D206  D2D4  F4A4  003119 | MVC   _temp19(7,r13,724),'
 ..'(r15,1188)
 003AC8  D203  D26C  1013  003119 | MVC
 _temp15(4,r13,620),_shadow18(r1,19)
 003ACE  4110  D26C003119 | LAr1,_temp15(,r13,620)
 003AD2  D202  D24C  1001  003119 | MVC
 _temp11(3,r13,588),_shadow12(r1,1)
 003AD8  4110  D24C003119 | LAr1,_temp11(,r13,588)
 003ADC  DE06  D2D4  1000  003119 | ED_temp19(7,r13,724),_temp11(r1,0)
 003AE2  D205  B000  D2D5  003119 | MVC
 _shadow21(6,r11,0),_temp19(r13,725)
 003AE8  5810  8000003119 | L r1,REPT_PTR(,r8,0)
 003AEC  D206  D2CC  F4A4  003119 | MVC   _temp21(7,r13,716),'
 ..'(r15,1188)
 003AF2  D202  D249  101B  003119 | MVC
 _temp18(3,r13,585),_shadow12(r1,27)
 003AF8  D202  D246  D249  003119 | MVC
 _temp20(3,r13,582),_temp18(r13,585)
 003AFE  4110  E028003119 | LAr1,#AddressShadow(,r14,40)
 003B02  E300  D246  0090  003119 | LLGC  r0,a1:d582:l1(,r13,582)
 003B08  E300  3114  0080  003119 | NGr0,=X' 000F'
 003B0E  41B0  D246003119 | LAr11,_temp20(,r13,582)
 003B12  4200  D246003119 | STC   r0,a1:d582:l1(,r13,582)
 003B16  DE06  D2CC  B000

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Lizette Koehler

Frank, enjoy your retirement.  You will be missed.  And know that DFSORT is
in very good hands.

Lizette

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Paul Gilmartin

On Wed, 16 May 2012 17:21:25 +0200, Miklos Szigetvari wrote:

Do you have the chance to compare the speed of the two codes ?
 
Does execution speed always trump code size?  Where should the
tradeoff be?  For example, any loop with a fixed number of
iterations (even a million) could be flattened to linear code; fewer
instructions executed; no test and branch.  (But it might yet be
slower because of instruction cache faults.)

-- gil

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

Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active

2012-05-16 Thread Dave Day

Does anyone know of any way to determine which diagnostic traps are 
active?  Is it possible?  Since my code makes heavy use of cell pools, 
IGVCPOOLFREEQ can have an impact on performance.


--Dave Day

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Tony's office PC

Agreed 100%, please enjoy all the many years ahead.  Speaking for myself, 
I'm totally confident that staff that's taking over will provide the 
excellent service we've enjoyed all these years.


Our list is losing another in that rare category of thread killer whose 
response to us finishes the discussion.






- Original Message - 
From: Lizette Koehler stars...@mindspring.com

Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@bama.ua.edu
Sent: Wednesday, May 16, 2012 11:03 AM
Subject: Re: Retiring after 43+ years with IBM


Frank, enjoy your retirement.  You will be missed.  And know that DFSORT 
is

in very good hands.

Lizette

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


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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Jerry Whitteridge

Frank - You will certainly be missed. Thanks for all your help over the
years. 

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Frank Yaeger
Sent: Tuesday, May 15, 2012 6:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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



Email Firewall made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

Re: Servicelink, ETR and SR

2012-05-16 Thread Eatherly, John D

This morning we had to start signing into IBM Service Request (SR)..

I opened ticket with IBM.  This was their response:

We and Level 2 already aware about this issue the we need to login twice
 when going to use Service Request. 
Level 2 has already started working on this hope this will be resolved soon.



John Eatherly

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

Re: Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active

2012-05-16 Thread Rob Scott

See ' SYS1.MODGEN(IGVDGNB)'

ECVT---ECVTDGNBDGNB

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Dave Day
Sent: 16 May 2012 17:20
To: IBM-MAIN@bama.ua.edu
Subject: Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active

 Does anyone know of any way to determine which diagnostic traps are 
active?  Is it possible?  Since my code makes heavy use of cell pools, 
IGVCPOOLFREEQ can have an impact on performance.

 --Dave Day

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

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Frank Yaeger

Elardus Engelbrecht at IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
wrote on 05/16/2012 12:10:22 AM:
 I'm happy to say that others on the DFSORT Team will continue to
contribute.

 Could you introduce them to us?

Well, you already know David Betten, the DFSORT performance expert, who has
been
posting on ibm-main for years.

My protege, Kolusu, here in San Jose,  will be replacing me on the function
side.
He has been posting solutions every day for years on the various MVS help
boards
(as have I). He will start posting on ibm-main as well.

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

 = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Tom Marchant

On Tue, 15 May 2012 20:07:52 +, Robert Prins wrote:

maybe a 16-byte
three-instruction sequence like

003FC0  E310  DF10  0158  003120 | LY   r1,a1:d7952:l4(,r13,7952)
003FC6  E300  1047  0015  003120 | LGH  r0,_shadow20(,r1,71)
003FCC  4000  E064003120 | STH  r0,_shadow20(,r14,100)

is really faster than the simple 6-byte one-instruction sequence

0026D4  D2 01 7 064 6 047  MVC   REPT_LINE.DATE.MONTH(2),REPT_LIST.DATE.MONTH

Not likely.

Address Generation Interlock (AGI) will cause the second instruction 
to stall until the address is available in R1.

In addition, instruction cracking will, under some circumstances, cause 
a z196 processor to execute a load and a store when a MVC instruction 
is executed.

-- 
Tom Marchant

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

Re: Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active

2012-05-16 Thread Dave Day


Rob,

Thanks.



On 5/16/2012 12:48 PM, Rob Scott wrote:

See ' SYS1.MODGEN(IGVDGNB)'

ECVT---ECVTDGNBDGNB

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Dave Day
Sent: 16 May 2012 17:20
To: IBM-MAIN@bama.ua.edu
Subject: Any way to programmatically detect diagnostic trap IGVCPOOLFREEQ active

  Does anyone know of any way to determine which diagnostic traps are 
active?  Is it possible?  Since my code makes heavy use of cell pools, 
IGVCPOOLFREEQ can have an impact on performance.

  --Dave Day

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

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



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

Re: Compiled SYSTEM Rexx exec

2012-05-16 Thread Ray Mullins


On 2012-05-15 12:35, Ed Mackmahon wrote:

Hi List.

We are zOS 1.12 shop.
I compiled and linked a Rexx exec which is supposed to run under AXR (system 
Rexx),
compile and link finished OK. After System Rexx server restated with the load 
dataset
concatenated, I got:

AXR0113I DATA SET S00.RCGAURD.SAXRLOAD ACCESSED THROUGH VOLSER(VPMVSE)
HAS INCORRECT RECORD FORMAT

How can I compile a Rexx exec that will run under the system Rexx server ?

Make absolutely sure you are creating a load module, not a CEXEC. The REXX 
compiler has all sorts of options governing the output of the compiler, and 
I can vouch that it's sometimes easy to slip up.


Cheers,
Ray

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Ray Mullins

Let me add to the chorus of thanks for your efforts and teaching over the 
decades. You will be sorely missed.


On 2012-05-15 18:00, Frank Yaeger wrote:

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!


--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Farley, Peter x23353

Frank,

Congratulations on your retirement.  Thank you for the immense help you have 
been to me and to many others on this list.  I and everyone else here will miss 
you.

May the road rise up to meet you.
May the wind be always at your back.
May the sun shine warm upon your face,
and rains fall soft upon your fields.
And until we meet again,
May God hold you in the palm of His hand.

All the best.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Frank Yaeger
Sent: Tuesday, May 15, 2012 9:00 PM
To: IBM-MAIN@bama.ua.edu
Subject: Retiring after 43+ years with IBM

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Bernd Oppolzer


First, I would like to thank you for starting this thread.

I posted it to the performance people of my customer, and they told me, that
they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE 
calls

don't generate MVCLs any more, as in previous releases, but series of MVCs
and loops. Even when the length of PLIMOVE is - for example - 8000 bytes.
They discovered it, because one of the PLIMOVE locations showed up in a 
Strobe report.


I asked them to test using a ASSEMBLER program, if the MVC loop is faster,
but they told me, that even with lengths around 500 or 600, the MVCL 
solution is faster

- this is on a z196. I have still to confirm this.

If this turns out to be true, this sounds like a bug, and we will try to 
convince IBM to go back to
the previous solution. If we compile our modules during normal service 
using EP PL/1 3.9,

our system will get slower and slower, because PLIMOVE is widely used.
This is not acceptable.

Because the PLIMOVEs are generated by a site-specific macro called PLICOPY,
I already thought about calling a short ASSEMBLER routine (with minimal 
linkage conventions)
doing the transfer using MVCL instead of CALL PLIMOVE. The applications 
need not
to be changed, because the PLICOPY syntax stays the same. Maybe this 
could still be

faster than doing the MVC loop.

Kind regards

Bernd



Am 16.05.2012 19:05, schrieb Robert Prins:

On 2012-05-16 14:59, Paul Gilmartin wrote:

On Wed, 16 May 2012 07:55:48 -0600, Steve Comstock wrote:


Well, I knew someone would raise that exception. No,
Metal C does not use LE. Not sure if SP C (Systems
Programmer C) is still around and it would be an
exception too.


I believe it's been discussed in these fora that C and PL/I
share an optimizer/code generator.  I hope this includes
Metal C.  It's a long leap of logic, but that might weaken the
argument for LE entanglement.  Is MOVE, BY NAME
plausibly dependent on LE?


For PL/I is is most definitely not, it's just a shortcut for lazy 
people and I've worked at sites that explicitly forbade its use, 
considering it just as bad as a SELECT * in SQL.


Robert


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

Re: Compiled SYSTEM Rexx exec

Ray,

Very true, also you may gain speed in computations but not I/O that was very 
clear in a Share presentation..

Scott ford
www.identityforge.com

On May 16, 2012, at 2:47 PM, Ray Mullins m...@lerctr.org wrote:

 On 2012-05-15 12:35, Ed Mackmahon wrote:
 Hi List.
 
 We are zOS 1.12 shop.
 I compiled and linked a Rexx exec which is supposed to run under AXR (system 
 Rexx),
 compile and link finished OK. After System Rexx server restated with the 
 load dataset
 concatenated, I got:
 
 AXR0113I DATA SET S00.RCGAURD.SAXRLOAD ACCESSED THROUGH VOLSER(VPMVSE)
 HAS INCORRECT RECORD FORMAT
 
 How can I compile a Rexx exec that will run under the system Rexx server ?
 
 Make absolutely sure you are creating a load module, not a CEXEC. The REXX 
 compiler has all sorts of options governing the output of the compiler, and I 
 can vouch that it's sometimes easy to slip up.
 
 Cheers,
 Ray
 
 -- 
 M. Ray Mullins
 Roseville, CA, USA
 http://www.catherdersoftware.com/
 
 German is essentially a form of assembly language consisting entirely of far 
 calls heavily accented with throaty guttural sounds. ---ilvi
 French is essentially German with messed-up pronunciation and spelling.  
 --Robert B Wilson
 English is essentially French converted to 7-bit ASCII.  ---Christophe 
 Pierret [for Alain LaBonté]
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Co-existance of z/OS and z/VM on same DASD farm

2012-05-16 Thread Ron MacRae

Hi all,
We are currently an exclusively z/OS site with multiple LPARs sharing a 
single IOCDS and DASD farm.  We are about to install z/VM in a new LPAR and I'm 
worried about both OSs sharing the same DASD farm. They will not be sharing at 
the volume level. 

I've read through the install doc and it all seems fine, you tell the install 
process 6 or 9 unit adresses and it goes and loads stuff onto them and then you 
IPL. There is no mention of modifying other volumes, however there are include 
and exclude unit address lists that you can specify to define what z/VM will 
try to look at, which presumably you can't get at until after the basic install 
and IPL. Also z/VM can issue sense commands to determine what devices are out 
there.

The reason I'm worried is that in a previous life, over 30 years ago, my 
previous company attempted to do the same between an VM system and a DOS/VSE 
system.  This was a long time ago on a real machine in pre LPAR days.
When they brought up VM for the first time it objected to the VSE VTOCs it 
found and rewrote them as OS VTOCs and we lost the whole DASD farm.  Management 
were not best pleased.  I wasn't directly involved at that time so I'm not 100% 
sure of my facts here and perhaps the guys who did this did something wrong, 
however my worry still remains.

My question is - Do we have to isolate z/VM from the z/OS volumes or will z/VM 
play nice and leave stuff alone?

I just want to double check that VM will only touch the 6 volumes it is given 
at install time.

Regards, Ron MacRae.

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

Re: Syslog missing

In 4fb286ac.8030...@bremultibank.com.pl, on 05/15/2012
   at 06:39 PM, R.S. r.skoru...@bremultibank.com.pl said:

I just noticed that syslog is dead.

Maybe, and maybe not.

Any clue?

Yes; query the status of HAEDCPY, OPERLOG and SYSLOG. Then examine
your SDSF, taking the query results into account.

When the command is issued on MCS console, it's also unavailable 
in the syslog

Have you actually verified that, or are you assuming that SDSF is
showing you everything in SYSLOG?

Any clue?

Examine and verify your assumptions.
 
-- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Co-existance of z/OS and z/VM on same DASD farm

2012-05-16 Thread McKown, John

In my past life, on VM/370 (yes that far back), VM always played nice with our 
MVT and MVS 3.8 system. VM has the concept of system owned volumes. You must 
specify these in a control file on the IPL volume. Also, VM does not use a z/OS 
type VTOC at all (well, there is a VOL1 and a 1 track VTOC which says no space 
available). It has its own formatting. The VM system will not try to use any 
volume itself which does not have a VM directory on it. You must create this 
using a VM utility. And VM itself, as opposed to a guest under VM, will not 
touch a volume which does not have this directory on it. IMO, it is more likely 
that z/OS will trash a z/VM volume than vice versa. I'd strongly suggest 
keeping the z/VM volumes off line to z/OS. z/OS does not play nice with 
others. It is a bit arrogant and thinks it is the only thing in your 
environment.

And, FWIW, we have run our current z/OS systems under z/VM for the past 5+ 
years at Sungard. We have never had a problem due to a z/VM malfunction.

IOW, you should not have any fears. The only fear would be if you deliberately 
ATTACHed a z/OS volume to a guest and the guest (such as CMS) were to write on 
the volume. 

There is a z/VM list available at mailto:lists...@listserv.uark.edu In the 
body: subscribe ibmvm Ron MacRae

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron MacRae
 Sent: Wednesday, May 16, 2012 3:04 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Co-existance of z/OS and z/VM on same DASD farm
 
 Hi all,
 We are currently an exclusively z/OS site with 
 multiple LPARs sharing a single IOCDS and DASD farm.  We are 
 about to install z/VM in a new LPAR and I'm worried about 
 both OSs sharing the same DASD farm. They will not be sharing 
 at the volume level. 
 
 I've read through the install doc and it all seems fine, you 
 tell the install process 6 or 9 unit adresses and it goes and 
 loads stuff onto them and then you IPL. There is no mention 
 of modifying other volumes, however there are include and 
 exclude unit address lists that you can specify to define 
 what z/VM will try to look at, which presumably you can't get 
 at until after the basic install and IPL. Also z/VM can issue 
 sense commands to determine what devices are out there.
 
 The reason I'm worried is that in a previous life, over 30 
 years ago, my previous company attempted to do the same 
 between an VM system and a DOS/VSE system.  This was a long 
 time ago on a real machine in pre LPAR days.
 When they brought up VM for the first time it objected to the 
 VSE VTOCs it found and rewrote them as OS VTOCs and we lost 
 the whole DASD farm.  Management were not best pleased.  I 
 wasn't directly involved at that time so I'm not 100% sure of 
 my facts here and perhaps the guys who did this did something 
 wrong, however my worry still remains.
 
 My question is - Do we have to isolate z/VM from the z/OS 
 volumes or will z/VM play nice and leave stuff alone?
 
 I just want to double check that VM will only touch the 6 
 volumes it is given at install time.
 
 Regards, Ron MacRae.
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
 
 

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

2012-05-16 Thread Mike Schwab

The Hercules group did some testing comparing MVCL to MVC.
If both source and destination had the same alignment to a double word
boundary, you could move 8 bytes, then increment the 4 registers to
reflect this, before being interuptable.  If they aligned differently
between boundaries, each 8 bytes would do this twice.

Whereas an MVC would do 256 bytes or less without interupting or
touching registers, and was much faster.

Of course, emulation is much different from hardware, ie, updating all
4 registers at once.

On Wed, May 16, 2012 at 2:41 PM, Bernd Oppolzer
bernd.oppol...@t-online.de wrote:
 First, I would like to thank you for starting this thread.

 I posted it to the performance people of my customer, and they told me, that
 they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE
 calls
 don't generate MVCLs any more, as in previous releases, but series of MVCs
 and loops. Even when the length of PLIMOVE is - for example - 8000 bytes.
 They discovered it, because one of the PLIMOVE locations showed up in a
 Strobe report.

 I asked them to test using a ASSEMBLER program, if the MVC loop is faster,
 but they told me, that even with lengths around 500 or 600, the MVCL
 solution is faster
 - this is on a z196. I have still to confirm this.

 If this turns out to be true, this sounds like a bug, and we will try to
 convince IBM to go back to
 the previous solution. If we compile our modules during normal service using
 EP PL/1 3.9,
 our system will get slower and slower, because PLIMOVE is widely used.
 This is not acceptable.

 Because the PLIMOVEs are generated by a site-specific macro called PLICOPY,
 I already thought about calling a short ASSEMBLER routine (with minimal
 linkage conventions)
 doing the transfer using MVCL instead of CALL PLIMOVE. The applications need
 not
 to be changed, because the PLICOPY syntax stays the same. Maybe this could
 still be
 faster than doing the MVC loop.

 Kind regards

 Bernd


-- 
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...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Servicelink, ETR and SR

2012-05-16 Thread Edward Jaffe


On 5/16/2012 3:46 AM, Barbara Nitz wrote:

Given that IBM took away ETR yesterday and has by now forced SR upon the 
mainframe world - do Americans coming from servicelink also have to login again 
to get to their ETRs??? Or is this 'privilege' reserved for EMEA?

Until ETR was taken away (yesterday morning our time) no extra login from 
Servicelink was required, SR was reachable using the normal servicelink login. 
I consider this an error and have opened a ticket.


I complained about this behavior during a closed meeting with Christian Gilmore 
and other IBMers at SHARE in Orlando back in February. Christian acknowledged 
the problem and made a note of it at the time, but nothing has been done to 
change it (yet).


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: Co-existance of z/OS and z/VM on same DASD farm

Ron,

I also did the same as John has MVS at that time under VM , with no issues.
The Sungard people were great, so if you have gaps in understanding or 
knowledge they help out in a DR situation. Almost all of the DR problems I have 
seen, done a ton of tests, turned out to be poor planning and execution.  I am 
of the mindset always, 'plan the work and work the plan'...


Scott ford
www.identityforge.com

On May 16, 2012, at 4:03 PM, Ron MacRae ronmac...@hotmail.co.uk wrote:

 Hi all,
We are currently an exclusively z/OS site with multiple LPARs sharing 
 a single IOCDS and DASD farm.  We are about to install z/VM in a new LPAR and 
 I'm worried about both OSs sharing the same DASD farm. They will not be 
 sharing at the volume level. 
 
 I've read through the install doc and it all seems fine, you tell the install 
 process 6 or 9 unit adresses and it goes and loads stuff onto them and then 
 you IPL. There is no mention of modifying other volumes, however there are 
 include and exclude unit address lists that you can specify to define what 
 z/VM will try to look at, which presumably you can't get at until after the 
 basic install and IPL. Also z/VM can issue sense commands to determine what 
 devices are out there.
 
 The reason I'm worried is that in a previous life, over 30 years ago, my 
 previous company attempted to do the same between an VM system and a DOS/VSE 
 system.  This was a long time ago on a real machine in pre LPAR days.
 When they brought up VM for the first time it objected to the VSE VTOCs it 
 found and rewrote them as OS VTOCs and we lost the whole DASD farm.  
 Management were not best pleased.  I wasn't directly involved at that time so 
 I'm not 100% sure of my facts here and perhaps the guys who did this did 
 something wrong, however my worry still remains.
 
 My question is - Do we have to isolate z/VM from the z/OS volumes or will 
 z/VM play nice and leave stuff alone?
 
 I just want to double check that VM will only touch the 6 volumes it is given 
 at install time.
 
 Regards, Ron MacRae.
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

Guys,

A little lost on the point of this thread , not trying be rude or flippant , 
just I see a lot about performance, is it valid with today's hardware and 
software, yes there is time sensitive events and software and hardware. 

Scott ford
www.identityforge.com

On May 16, 2012, at 4:35 PM, Mike Schwab mike.a.sch...@gmail.com wrote:

 The Hercules group did some testing comparing MVCL to MVC.
 If both source and destination had the same alignment to a double word
 boundary, you could move 8 bytes, then increment the 4 registers to
 reflect this, before being interuptable.  If they aligned differently
 between boundaries, each 8 bytes would do this twice.
 
 Whereas an MVC would do 256 bytes or less without interupting or
 touching registers, and was much faster.
 
 Of course, emulation is much different from hardware, ie, updating all
 4 registers at once.
 
 On Wed, May 16, 2012 at 2:41 PM, Bernd Oppolzer
 bernd.oppol...@t-online.de wrote:
 First, I would like to thank you for starting this thread.
 
 I posted it to the performance people of my customer, and they told me, that
 they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE
 calls
 don't generate MVCLs any more, as in previous releases, but series of MVCs
 and loops. Even when the length of PLIMOVE is - for example - 8000 bytes.
 They discovered it, because one of the PLIMOVE locations showed up in a
 Strobe report.
 
 I asked them to test using a ASSEMBLER program, if the MVC loop is faster,
 but they told me, that even with lengths around 500 or 600, the MVCL
 solution is faster
 - this is on a z196. I have still to confirm this.
 
 If this turns out to be true, this sounds like a bug, and we will try to
 convince IBM to go back to
 the previous solution. If we compile our modules during normal service using
 EP PL/1 3.9,
 our system will get slower and slower, because PLIMOVE is widely used.
 This is not acceptable.
 
 Because the PLIMOVEs are generated by a site-specific macro called PLICOPY,
 I already thought about calling a short ASSEMBLER routine (with minimal
 linkage conventions)
 doing the transfer using MVCL instead of CALL PLIMOVE. The applications need
 not
 to be changed, because the PLICOPY syntax stays the same. Maybe this could
 still be
 faster than doing the MVC loop.
 
 Kind regards
 
 Bernd
 
 
 -- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)

Oh, now i see what Bernd was talking about, sorry guys , old age

Scott ford
www.identityforge.com

On May 16, 2012, at 4:53 PM, Scott Ford scott_j_f...@yahoo.com wrote:

 Guys,
 
 A little lost on the point of this thread , not trying be rude or flippant , 
 just I see a lot about performance, is it valid with today's hardware and 
 software, yes there is time sensitive events and software and hardware. 
 
 Scott ford
 www.identityforge.com
 
 On May 16, 2012, at 4:35 PM, Mike Schwab mike.a.sch...@gmail.com wrote:
 
 The Hercules group did some testing comparing MVCL to MVC.
 If both source and destination had the same alignment to a double word
 boundary, you could move 8 bytes, then increment the 4 registers to
 reflect this, before being interuptable.  If they aligned differently
 between boundaries, each 8 bytes would do this twice.
 
 Whereas an MVC would do 256 bytes or less without interupting or
 touching registers, and was much faster.
 
 Of course, emulation is much different from hardware, ie, updating all
 4 registers at once.
 
 On Wed, May 16, 2012 at 2:41 PM, Bernd Oppolzer
 bernd.oppol...@t-online.de wrote:
 First, I would like to thank you for starting this thread.
 
 I posted it to the performance people of my customer, and they told me, that
 they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE
 calls
 don't generate MVCLs any more, as in previous releases, but series of MVCs
 and loops. Even when the length of PLIMOVE is - for example - 8000 bytes.
 They discovered it, because one of the PLIMOVE locations showed up in a
 Strobe report.
 
 I asked them to test using a ASSEMBLER program, if the MVC loop is faster,
 but they told me, that even with lengths around 500 or 600, the MVCL
 solution is faster
 - this is on a z196. I have still to confirm this.
 
 If this turns out to be true, this sounds like a bug, and we will try to
 convince IBM to go back to
 the previous solution. If we compile our modules during normal service using
 EP PL/1 3.9,
 our system will get slower and slower, because PLIMOVE is widely used.
 This is not acceptable.
 
 Because the PLIMOVEs are generated by a site-specific macro called PLICOPY,
 I already thought about calling a short ASSEMBLER routine (with minimal
 linkage conventions)
 doing the transfer using MVCL instead of CALL PLIMOVE. The applications need
 not
 to be changed, because the PLICOPY syntax stays the same. Maybe this could
 still be
 faster than doing the MVC loop.
 
 Kind regards
 
 Bernd
 
 
 -- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Re: Co-existence of z/OS and z/VM on same DASD farm

2012-05-16 Thread Jerry Whitteridge

We let z/VM sense all volumes and z/OS owns the IODF and IOCDS's. We've had 
zero issues with z/VM touching volumes it isn't supposed to. 

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ron MacRae
Sent: Wednesday, May 16, 2012 1:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Co-existance of z/OS and z/VM on same DASD farm

Hi all,
We are currently an exclusively z/OS site with multiple LPARs sharing a 
single IOCDS and DASD farm.  We are about to install z/VM in a new LPAR and I'm 
worried about both OSs sharing the same DASD farm. They will not be sharing at 
the volume level. 

I've read through the install doc and it all seems fine, you tell the install 
process 6 or 9 unit adresses and it goes and loads stuff onto them and then you 
IPL. There is no mention of modifying other volumes, however there are include 
and exclude unit address lists that you can specify to define what z/VM will 
try to look at, which presumably you can't get at until after the basic install 
and IPL. Also z/VM can issue sense commands to determine what devices are out 
there.

The reason I'm worried is that in a previous life, over 30 years ago, my 
previous company attempted to do the same between an VM system and a DOS/VSE 
system.  This was a long time ago on a real machine in pre LPAR days.
When they brought up VM for the first time it objected to the VSE VTOCs it 
found and rewrote them as OS VTOCs and we lost the whole DASD farm.  Management 
were not best pleased.  I wasn't directly involved at that time so I'm not 100% 
sure of my facts here and perhaps the guys who did this did something wrong, 
however my worry still remains.

My question is - Do we have to isolate z/VM from the z/OS volumes or will z/VM 
play nice and leave stuff alone?

I just want to double check that VM will only touch the 6 volumes it is given 
at install time.

Regards, Ron MacRae.

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


Email Firewall made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

TS7700 Scheduled Downtime Procedures

2012-05-16 Thread David G. Schlecht

We’ve switched to using the TS7720 as a stand-alone VTS and are planning an 
outage this weekend for microcode upgrade.

In the old days, for an outage we had to:

1.   Vary the libraries offline

2.   Vary the drives offline

3.   Vary the chanel paths offline

4.   When varying the final drives off line, we had to use Force because 
they were the last attached devices.

Looking over the Planning and Intro book and the Virtual Engine book 
(SG24-7712-02) it appears the same procedures are needed for today’s VTS. Is 
there anything else that is required or something else to watch for with 
today’s TS7700?


David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- New Address



This communication, including any attachments, may contain confidential 
information and is intended only for the individual or entity to which it is 
addressed. Any review, dissemination or copying of this communication by anyone 
other than the intended recipient is strictly prohibited. If you are not the 
intended recipient, please contact the sender by reply e-mail and delete all 
copies of the original message.

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

Re: Compiled SYSTEM Rexx exec

2012-05-16 Thread John Gilmore

Still better, make absolutely sure that you are creating a program
object stored in a PDSE.

On 5/16/12, Scott Ford scott_j_f...@yahoo.com wrote:
 Make absolutely sure you are creating a load module, not a CEXEC. The REXX
 compiler has all sorts of options governing the output of the compiler,
 and I can vouch that it's sometimes easy to slip up.

 Cheers,
 Ray


John Gilmore, Ashland, MA 01721 - USA

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

Re: TS7700 Scheduled Downtime Procedures

2012-05-16 Thread David G. Schlecht

I just submitted this question to IBM. 


David G. Schlecht | Information Technology Professional
State of Nevada | Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- New Address


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
David G. Schlecht
Sent: Wednesday, May 16, 2012 2:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: TS7700 Scheduled Downtime Procedures

We’ve switched to using the TS7720 as a stand-alone VTS and are planning an 
outage this weekend for microcode upgrade.

In the old days, for an outage we had to:

1.   Vary the libraries offline

2.   Vary the drives offline

3.   Vary the chanel paths offline

4.   When varying the final drives off line, we had to use Force because 
they were the last attached devices.

Looking over the Planning and Intro book and the Virtual Engine book 
(SG24-7712-02) it appears the same procedures are needed for today’s VTS. Is 
there anything else that is required or something else to watch for with 
today’s TS7700?


David G. Schlecht | Information Technology Professional State of Nevada | 
Department of Administration | Enterprise IT Services
T:(775)684-4328 | F: (775) 684‐4324 | E:dschle...@admin.nv.gov -- New Address



This communication, including any attachments, may contain confidential 
information and is intended only for the individual or entity to which it is 
addressed. Any review, dissemination or copying of this communication by anyone 
other than the intended recipient is strictly prohibited. If you are not the 
intended recipient, please contact the sender by reply e-mail and delete all 
copies of the original message.

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

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

Re: It's feeding time in Jurassic Park . . .

2012-05-16 Thread Kerneels


George,

IBM needs you tomorrow.. because now they are asking a Magazine Editor 
and a professional presenter to do, what YOU tried to do on this 
list.. all on your own.. from your basement.


http://www.youtube.com/watch?v=o22i_gqAf_o

You and your Fox channel are more qualified to talk about the subject.. 
with a little help from your friend in Singapore.


Here is the posting/notification :

Don't forget to register for tomorrow's live webcast on Enterprise Linux 
Servers with IDC's Jean Bozman


http://event.on24.com/clients/ibm/395160?partnerref=FACEBOOK
event.on24.com

Comments about the posting/notification :
Jean Bozman/Dennis Wunder are both magazine editor/presenters, according 
to their online profiles.
Are there no real technical people in IBM .. still standing that can 
talk about real life experiences any more ?
Personally, I think the smoke  mirror marketing period in our IT 
history is all over


http://www.youtube.com/watch?v=ZHwVBirqD2sfeature=related

Elton John - I'm Still Standing
www.youtube.com
Music video by Elton John performing I'm Still Standing. (C) 1983 
Mercury Records Limited


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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Rick Fochtman


On 5/15/2012 8:00 PM, Frank Yaeger wrote:

Just a note to let everyone know I'll be retiring at the end
of this month (5/31/2012).  I've been with IBM for 43+ years
(plus a couple of summers in college) and I've enjoyed my
career immensely.  I've especially enjoyed being able to
help people use the DFSORT/ICETOOL functions I developed,
over many years, in new and interesting ways.

Once I retire, I won't be posting solutions any more since I
won't have access to a mainframe to test them, and I don't
like posting untested solutions.  I may lurk a bit or I may
not.

I'm looking forward to retirement, but I'll also miss this
list.  I'm happy to say that others on the DFSORT Team will
continue to contribute.

Thanks to everyone for giving me the chance to earn a living
all these years doing something that was a lot of fun for
me.

Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL!

Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration

  =  DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort

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

Frank, may you enjoy many happy years of retirement. Enjoy all the grand 
kids, too.


Rick

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

Re: Retiring after 43+ years with IBM

2012-05-16 Thread Frank Yaeger

Rick Fochtman at IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote
on 05/16/2012 03:49:01 PM:
 
 Enjoy all the grandkids, too.

No grandkids, but granddogs, and our beloved pet rats, to enjoy :-)
Our four pet rats will be very happy to have me at home more since
that means even more out-of-cage playtime for them.

Frank

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

Re: Retiring after 43+ years with IBM