documentation/manual with all HMC log messages

[Dr. Stephen Fedtke]

hi all,

we are unable to identify the manual/documenation including and explaining
all HMC log messages.
it concerns messages like


Fri Sep 12 07:08:55 CEST 20yy  xx  Starting remote support call
20xx-xx-xx 07:08:54 AM for console HMC11(xx). Type: ACT01693I Requesting
MCLs for HMC. 


thanks for your help
stephen


---
Dr. Stephen Fedtke
Enterprise-IT-Security.com

Seestrasse 3a
CH-6300  Zug
Switzerland
Tel. ++41-(0)41-710-4005
www.enterprise-it-security.com


++NEWS++ SF-NoEvasion lets you avoid all 10 pitfalls when connecting z/OS to
your SIEM ++NEWS++

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

Re: Entry point on attach

[Andy Wood]

On Fri, 17 Feb 2012 17:21:12 -0500, Micheal Butz  
wrote:

>Hi
>
>Again if I do a attach with disp=no
>And r1 has the tcb address I can look at the TCBRBP or relating CDE for the 
>loadpoint of the module
>

I'm not quite sure what you mean, but if you only did ATTACH with DISP=NO, then 
the attach will not have completed. Since the loading of the module (if 
necessary) will be done by the newly created task, I don't think you will find 
anything useful in the control blocks until you let the subtask run.

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

Re: Program entry point on Attached program

[Binyamin Dissen]

On Fri, 17 Feb 2012 16:24:24 -0500 Micheal Butz 
wrote:

:>I know that if a program is re-entrant a subsequent ATTACH will use that
:>address as the entry point.

:>How about a non-reentrant program

It shouldn't.

:>If I do a ATTACH DISP=NO is the attached program LOADED and if so is there a
:>way to find the entry point

AFAIK, the new task has not gone that far yet. 

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: 'SYS1.PARMLIB(ALLOCxx)'

[Binyamin Dissen]

On Fri, 17 Feb 2012 23:29:31 -0600 Paul Schuster 
wrote:

:>Is it possible to dynamically (from a program) determine some of the settings 
(or defaults) in SYS1.PARMLIB(ALLOCxx)'? I am interested in determining the SVC 
99 defaults.

Look at SHOWMVS label ALLOC00. It should be the first thing you check for
questions like that.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Ed Gould]

We are all pretty much knowledgeable about how the MF works in the  
multi-volume  area, right?


The secondary question I am asking is how does the PC create/handle  
multivolume files?


I can guess but that is pretty much all it is. Can anyone explain it  
for the PC ?


Ed

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

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[zMan]

Sure: it doesn't. Unless you're using some other sort of volume manager.

Of course, with a 1TB drive selling for less than $100, multivolume
files aren't usually a requirement...

On Sat, Feb 18, 2012 at 2:43 PM, Ed Gould  wrote:
> We are all pretty much knowledgeable about how the MF works in the
> multi-volume  area, right?
>
> The secondary question I am asking is how does the PC create/handle
> multivolume files?
>
> I can guess but that is pretty much all it is. Can anyone explain it for the
> PC ?
>
> Ed
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Scott Ford]

Ed,
Or maybe they use the famous four letter word, plan and have a harddrive big 
enough to handle the file

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 18, 2012, at 5:43 PM, Ed Gould  wrote:

> We are all pretty much knowledgeable about how the MF works in the 
> multi-volume  area, right?
> 
> The secondary question I am asking is how does the PC create/handle 
> multivolume files?
> 
> I can guess but that is pretty much all it is. Can anyone explain it for the 
> PC ?
> 
> Ed
> 
> --
> 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: documentation/manual with all HMC log messages

[R.S.]

W dniu 2012-02-18 12:06, Dr. Stephen Fedtke pisze:

hi all,

we are unable to identify the manual/documenation including and explaining
all HMC log messages.
it concerns messages like


Fri Sep 12 07:08:55 CEST 20yy  xx  Starting remote support call
20xx-xx-xx 07:08:54 AM for console HMC11(xx). Type: ACT01693I Requesting
MCLs for HMC.


AFAIK there is no such documentation available (to users).


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

Re: Subject: SV: REXX IEBCOPY Continuation?

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 08:14 AM, Mark Jones  said:

>"FREE F(INDD1)" 
>"FREE F(OUTDD1)" 
>"FREE F(SYSIN)" 
>"ALLOC FI(INDD1) DSN('x..aaa') SHR" 
>"ALLOC FI(OUTDD1) DSN('x..bbb') SHR" 
>"ALLOC FI(SYSIN) DSN('x..ccc') SHR" 

Why not

 "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR" 
 "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR" 
 "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR" 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: zSeries Manpower Sizing

[Shmuel Metz (Seymour J.)]

In
,
on 02/16/2012
   at 04:18 PM, George Henke  said:

>I am trying to find out how much staff, numbers and titles, eg z/OS,
>z/VM, VTAM/TCPIP, CICS, etc, are needed to run a large zSeries
>mainframe shop.

What are their duties? That includes things that they nominally aren't
responsible for but where other departments are understaffed or
undertrained and require hand-holding. The sizing depends very much on
organizational details.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: SV: REXX IEBCOPY Continuation?

[Shmuel Metz (Seymour J.)]

In
,
on 02/15/2012
   at 09:17 PM, Thomas Berg  said:

>I guess that what You want is:

>"NEWSTACK"
>V1 = "COPY1 COPY INDD=INDD1,OUTDD=OUTDD1"
>V2 = "S M=DBOK62"
>V3 = "S M=DP13"
>V4 = "S M=LAND1CPY"
>V5 = "S M=SSTDN"
>V6 = "S M=TRAY2LN"
>Queue V1 
>Queue V2
>Queue V3
>Queue V4
>Queue V5
>Queue V6
>"EXECIO" queued() "DISKW SYSIN (FINIS"
>"DELSTACK"
>"TSOEXEC IEBCOPY"

NFW; it's missing the leading spaces.

"NEWSTACK"
Queue  " COPY1 COPY INDD=INDD1,OUTDD=OUTDD1" 
Queue " S M=DBOK62"
Queue " S M=DP13"
Queue " S M=LAND1CPY"
Queue " S M=SSTDN"
Queue " S M=TRAY2LN"
"EXECIO" queued() "DISKW SYSIN (FINIS"
"DELSTACK"
"CALL *(IEBCOPY)" /* needs APF and standard PARM */
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Paul Gilmartin]

On Sat, 18 Feb 2012 16:43:27 -0600, Ed Gould wrote:
>
>The secondary question I am asking is how does the PC create/handle
>multivolume files?
> 
Virtual volumes as big as needed:  RAID; ZFS; ...?

Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.

-- gil

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

Re: Subject: SV: REXX IEBCOPY Continuation?

[Mike Schwab]

Another program could have those DDNAMEs assigned to different DSNAMEs.

On Sat, Feb 18, 2012 at 5:38 PM, Shmuel Metz (Seymour J.)
 wrote:
> In
> ,
> on 02/16/2012
>   at 08:14 AM, Mark Jones  said:
>
>>"FREE F(INDD1)"
>>"FREE F(OUTDD1)"
>>"FREE F(SYSIN)"
>>"ALLOC FI(INDD1) DSN('x..aaa') SHR"
>>"ALLOC FI(OUTDD1) DSN('x..bbb') SHR"
>>"ALLOC FI(SYSIN) DSN('x..ccc') SHR"
>
> Why not
>
>  "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
>  "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
>  "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"
>
> --
>     Shmuel (Seymour J.) Metz, SysProg and JOAT
>     ISO position; see 
> 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



-- 
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Mike Schwab]

Under Linux / AIX, You can define a logical volume that spans multiple
physical volumes.  And different mount points can point to different
physical drives.  But reading from the root / it all looks like one
logical drive.

Windows has different drive letters for each drive or hard drive
partition or usb / CD / DVD drive.

And you can have a link where a file name points to another file name.

Neither Windows or Linux have a Catalog concept to find a dataset on
any of 64,000 or so disk drives (I have 2400 at work).

On Sat, Feb 18, 2012 at 4:43 PM, Ed Gould  wrote:
> We are all pretty much knowledgeable about how the MF works in the
> multi-volume  area, right?
>
> The secondary question I am asking is how does the PC create/handle
> multivolume files?
>
> I can guess but that is pretty much all it is. Can anyone explain it for the
> PC ?
>
> Ed

-- 
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: Archaic allocation in JCL (Was: Physical record size query)

[Robert A. Rosenberg]

At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic 
allocation in JCL (Was: Physical record size qu:


The "gotcha" used to be that if you grossly over-requested space, 
got space dispersed over umpteen volumes, only used a little of the 
space, that "RLSE" would then only release the unused space on the 
last volume actually written and leave all the unneeded, unused 
space on subsequent volumes allocated until the data set was deleted.


This could be fixed by defining a RLSEALL parm (which would not only 
release the unused space on the last used volume but also release all 
the extra volumes). This could be in the JCL or better SMS (since SMS 
is doing the allocation in the first place). I regard this failure as 
a Design Flaw AKA Bug.


Query - If I have a multi-volume existent dataset that I allocate as 
DISP=OLD and open as output (thus rewriting from the start) which has 
SPACE coded as RLSE does it release the space on volumes past the one 
that was used or also just the unused extents on the last written 
volume?


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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Robert A. Rosenberg]

At 14:07 -0500 on 02/17/2012, Shmuel Metz (Seymour J.) wrote about 
Re: Archaic allocation in JCL (Was: Physical record size qu:



In
,
on 02/17/2012
   at 12:50 PM, John Gilmore  said:


is not really wrongheaded.  It is an unfortunate oversimplification
for real DASD.


Not if you were only discussing conversion of the SPACE parameter. I
agree that carrying over BLKSIZE from generation to generation is
ghastly, albeit far too common.


I agree. OTOH: There are programs that were converted from DOS to MVS 
(or were written by ex-DOS programmers) which have hard coded 
Blocksizes instead of letting the dataset define them. Thus they stay 
constant no matter what device you use.


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

Re: Program entry point on Attached program

[Peter Relson]

>If I do a ATTACH DISP=NO is the attached program LOADED
No, until after ATTACH DISP=RESET.
In any ATTACH scenario, the attached program is loaded under the
(running) new task. The new task does not run at all until
ATTACH DISP=RESET.

Peter Relson
z/OS Core Technology Design

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[Clark Morris]

On 18 Feb 2012 17:53:19 -0800, in bit.listserv.ibm-main you wrote:

>At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic 
>allocation in JCL (Was: Physical record size qu:
>
>>The "gotcha" used to be that if you grossly over-requested space, 
>>got space dispersed over umpteen volumes, only used a little of the 
>>space, that "RLSE" would then only release the unused space on the 
>>last volume actually written and leave all the unneeded, unused 
>>space on subsequent volumes allocated until the data set was deleted.
>
>This could be fixed by defining a RLSEALL parm (which would not only 
>release the unused space on the last used volume but also release all 
>the extra volumes). This could be in the JCL or better SMS (since SMS 
>is doing the allocation in the first place). I regard this failure as 
>a Design Flaw AKA Bug.
>
>Query - If I have a multi-volume existent dataset that I allocate as 
>DISP=OLD and open as output (thus rewriting from the start) which has 
>SPACE coded as RLSE does it release the space on volumes past the one 
>that was used or also just the unused extents on the last written 
>volume?

For VSAM I would still allocate in either tracks or cylinders so that
I get the CA size I want.  Of course if allocation is in millions of
anything, that caveat doesn't matter (or have they changed VSAM so a
CA can be larger than a cylinder?).

Clark Morris

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

Re: z/OS Feeding SolarWinds

[Clark Morris]

On 17 Feb 2012 06:25:10 -0800, in bit.listserv.ibm-main you wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List 
>> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason
>> Sent: Friday, February 17, 2012 4:18 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: z/OS Feeding SolarWinds
>> 
>> Jim
>> 
>> Your title could be restated as "The SNMP Agent supported by 
>> z/OS 'feeding' the SNMP Manager which happens to be supported 
>> by SolarWinds".
>> 
>> The point about the title change is that the "P" in "SNMP" 
>> means "protocol" and thus SNMP is designed to support any old 
>> IP platform as an SNMP agent and any old IP platform as an 
>> SNMP manager and the two will work harmoniously together!
>
>So true. In another message I told how we use it. We had some problems which 
>the other side said was with us. So I simply redirected the SNMP messages from 
>their server to my Linux desktop. I used "tcpdump" on my desktop to show them 
>that z/OS was indeed sending out SNMP messages and that they were properly 
>formatted. They then went back and figured out what was wrong with their 
>server. But, around here, any intercommunication problem is automatically 
>assumed to be a z/OS failure until proven otherwise. Because they __know__ 
>that Windows always works correctly!


Don't they read the details that come with the Microsoft updates and
don't look at knowledge base entries.  There is a wealth of
information available at the Microsoft web-site for anyone who cares
to take the effort.

Clark Morris

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

Re: Archaic allocation in JCL (Was: Physical record size query)

[R.S.]

W dniu 2012-02-19 03:34, Clark Morris pisze:
[...]

For VSAM I would still allocate in either tracks or cylinders so that
I get the CA size I want.  Of course if allocation is in millions of
anything, that caveat doesn't matter (or have they changed VSAM so a
CA can be larger than a cylinder?).


They've changed CA lately (z/OS 1.10), but not to increase it. Now the 
CA have to be divisor of 315 - that means: 1,3,5,7,9,15 trks.

Reason: EAV (allocation is done in 21-cylinder chunks).

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

Re: Very Lage Page Datasets (was ASM and HiperPAV)

[Walter Medenbach]

Two years back we had an issue where the throughput of a database utility
dropped considerably (job had to be cancelled because it was too slow)
because it decided to not use more memory to do it's processing. This was
found to be  because the page datasets were more than 50% utilized. The
notes below are from my analysis of the problem at the time.

Some software will believe that the system is storage constrained if the
page datasets are at or near 50% full.   The software affected   use the
SYSEVENT STGTEST macro to determine how much storage it can use without
affecting system paging performance. The returned values are used to set
maximum sizes for such things as memory work areas. If these are small then
the programs will be inefficient and use significantly more cpu and do more
IOs. This should be considered when determining page dataset size.

SYSEVENT STGTST behaviour from Authorized assembler Services reference
manual:

After SRM returns, each word contains a storage amount that represents a
specific number of frames. Before you choose a number to use as the basis
for decision, be aware of how your decision affects the performance of the
system. The meaning of the returned values is:
Use of the first number will affect system performance very little, if at
all.
Use of the second number might affect system performance to some degree.
Use of the third number might substantially affect system performance.

If you base decisions on the value in the second or third word, SRM may
have to take processor storage away from other programs and replace it with
auxiliary storage.
If you are running your system in workload management goal mode, the value
returned in the third word will always be the same as the value returned in
the second word.

APAR OA20116 has a note throws some light on how the second word returned
from SYSEVENT STGTST is calculated:

Problem conclusion
The logic in IRAEVREQ was changed in a way, that the maximum of
the return value 1 and return value 2 is used as return value 2
and return value 3.

Additionally the logic in IRAEVREQ ensures that the value
returned in words 2 and 3 do not drive the system into an
auxiliary storage shortage.  The value returned in words 2 and 3
will only fill the AUX subsystem up to 50%.

Examples:
If the AUX subsystem is filled by 25% and the return value 1
contains 1000 frames.  Then the return value 2 and 3 are set to
1000 frames + 25% of the AUX slots.

Walter Medenbach

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

Re: Subject: SV: REXX IEBCOPY Continuation?

[Paul Gilmartin]

On Sat, 18 Feb 2012 18:38:28 -0500, Shmuel Metz (Seymour J.) wrote:
>
>Why not
>
> "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
> "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
> "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"
> 
A prior operation might have allocated those DDNAMEs to UNIX
paths and neglected to free them.

-- gil

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

Re: Subject: SV: REXX IEBCOPY Continuation?

[Paul Gilmartin]

On Sat, 18 Feb 2012 18:58:50 -0600, Mike Schwab wrote:

>Another program could have those DDNAMEs assigned to different DSNAMEs.
> 
Do you believe that an allocate command with the REUSE option would
fail to free a DDNAME allocated to a DSNAME?

>On Sat, Feb 18, 2012 at 5:38 PM, Shmuel Metz (Seymour J.) wrote:
>>
>> Why not
>>
>>  "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
>>  "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
>>  "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"

-- gil

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

SMTP and attachements

[Munif Sadek]

Dear listers

Please point me in the right direction.. I am trying to send a small VB, LRECL 
>500 bytes file as an attachment via SMTP from my  z/OS 1.13 without much 
success..

is it possible? any working smaple?

regards 
Munif

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

Re: SV: REXX IEBCOPY Continuation?

[retired mainframer]

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Shmuel Metz (Seymour J.)
:>: Sent: Saturday, February 18, 2012 3:51 PM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Re: SV: REXX IEBCOPY Continuation?
:>:
:>: In
:>:
,
:>: on 02/15/2012
:>:at 09:17 PM, Thomas Berg  said:
:>:
:>: >I guess that what You want is:
:>:
:>: >"NEWSTACK"
:>: >V1 = "COPY1 COPY INDD=INDD1,OUTDD=OUTDD1"
:>: >V2 = "S M=DBOK62"
:>: >V3 = "S M=DP13"
:>: >V4 = "S M=LAND1CPY"
:>: >V5 = "S M=SSTDN"
:>: >V6 = "S M=TRAY2LN"
:>: >Queue V1
:>: >Queue V2
:>: >Queue V3
:>: >Queue V4
:>: >Queue V5
:>: >Queue V6
:>: >"EXECIO" queued() "DISKW SYSIN (FINIS"
:>: >"DELSTACK"
:>: >"TSOEXEC IEBCOPY"
:>:
:>: NFW; it's missing the leading spaces.
:>:
:>: "NEWSTACK"
:>: Queue  " COPY1 COPY INDD=INDD1,OUTDD=OUTDD1"
:>: Queue " S M=DBOK62"
:>: Queue " S M=DP13"
:>: Queue " S M=LAND1CPY"
:>: Queue " S M=SSTDN"
:>: Queue " S M=TRAY2LN"
:>: "EXECIO" queued() "DISKW SYSIN (FINIS"
:>: "DELSTACK"
:>: "CALL *(IEBCOPY)" /* needs APF and standard PARM */

Of course, you meant for COPY1 to be in col 1 on the first queue command.

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

Re: Subject: SV: REXX IEBCOPY Continuation?

[retired mainframer]

The REUSE operand will cause ALLOC to free the DD name currently if it is
currently in use.

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Mike Schwab
:>: Sent: Saturday, February 18, 2012 4:59 PM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Re: Subject: SV: REXX IEBCOPY Continuation?
:>:
:>: Another program could have those DDNAMEs assigned to different DSNAMEs.
:>:
:>: On Sat, Feb 18, 2012 at 5:38 PM, Shmuel Metz (Seymour J.)
:>:  wrote:
:>: > In
:>: >
,
:>: > on 02/16/2012
:>: >   at 08:14 AM, Mark Jones  said:
:>: >
:>: >>"FREE F(INDD1)"
:>: >>"FREE F(OUTDD1)"
:>: >>"FREE F(SYSIN)"
:>: >>"ALLOC FI(INDD1) DSN('x..aaa') SHR"
:>: >>"ALLOC FI(OUTDD1) DSN('x..bbb') SHR"
:>: >>"ALLOC FI(SYSIN) DSN('x..ccc') SHR"
:>: >
:>: > Why not
:>: >
:>: >  "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
:>: >  "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
:>: >  "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"

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

Re: Subject: SV: REXX IEBCOPY Continuation?

[retired mainframer]

:>: -Original Message-
:>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:>: Behalf Of Paul Gilmartin
:>: Sent: Saturday, February 18, 2012 7:56 PM
:>: To: IBM-MAIN@bama.ua.edu
:>: Subject: Re: Subject: SV: REXX IEBCOPY Continuation?
:>:
:>: On Sat, 18 Feb 2012 18:38:28 -0500, Shmuel Metz (Seymour J.) wrote:
:>: >
:>: >Why not
:>: >
:>: > "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
:>: > "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
:>: > "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"
:>: >
:>: A prior operation might have allocated those DDNAMEs to UNIX
:>: paths and neglected to free them.

But the REUSE operand will free the DD name in that case.

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

Re: SMTP and attachements

[Scott Ford]

Munif,

A little more information would be helpfulfrom Z/os to ? Why not FTP ?

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 18, 2012, at 11:32 PM, Munif Sadek  wrote:

> Dear listers
> 
> Please point me in the right direction.. I am trying to send a small VB, 
> LRECL >500 bytes file as an attachment via SMTP from my  z/OS 1.13 without 
> much success..
> 
> is it possible? any working smaple?
> 
> regards 
> Munif
> 
> --
> 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: SMTP and attachements

[Mike Schwab]

I have done some Fixed length emails.  Have you tried copying to a
fixed length record with trailing blanks and sending it?  Used to be a
length limit abour 240-255 because of JES.

On Sat, Feb 18, 2012 at 11:59 PM, Scott Ford  wrote:
> Munif,
>
> A little more information would be helpfulfrom Z/os to ? Why not FTP ?
>
> Sent from my iPad
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
>
>
>
> On Feb 18, 2012, at 11:32 PM, Munif Sadek  wrote:
>
>> Dear listers
>>
>> Please point me in the right direction.. I am trying to send a small VB, 
>> LRECL >500 bytes file as an attachment via SMTP from my  z/OS 1.13 without 
>> much success..
>>
>> is it possible? any working smaple?
>>
>> regards
>> Munif
>>
>> --
>> 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



-- 
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: Subject: SV: REXX IEBCOPY Continuation?

[Paul Gilmartin]

On Sat, 18 Feb 2012 21:30:34 -0800, retired mainframer wrote:
>:>: >
>:>: > "ALLOC FI(INDD1) DSN('x..aaa') REUSE SHR"
>:>: > "ALLOC FI(OUTDD1) DSN('x..bbb') REUSE SHR"
>:>: > "ALLOC FI(SYSIN) DSN('x..ccc') REUSE SHR"
>:>: >
>:>: A prior operation might have allocated those DDNAMEs to UNIX
>:>: paths and neglected to free them.
>
>But the REUSE operand will free the DD name in that case.
> 
I stand corrected.  You can't use REUSE when the new allocation
is to a PATH; experiment shows it works when the prior allocation
is to a PATH and the new allocation to a DSNAME.  (z/OS 1.13)

-- gil

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

Programmer cleared of stealing goldman sachs code

[Mike Schwab]

http://www.guardian.co.uk/technology/2012/feb/18/programmer-cleared-stealing-goldman-sachs


During a two-week trial, defence lawyer Kevin Marino told jurors that
his client had merely tried to copy parts of the company's software
that came from public software code anyway. He acknowledged that
Aleynikov had violated the company's confidentiality agreements but
argued that was a civil matter.

A three-judge appeals panel heard arguments on Thursday but the judges
gave no indication they would overturn the lower court verdict hours
later with a terse, one-paragraph order. The court said it would issue
a written ruling "in due course" to explain its decision.

-- 
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Edward Jaffe]

On 2/18/2012 4:45 PM, Paul Gilmartin wrote:

Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.


In that case, widespread adoption of 1TB volumes on z/OS should significantly 
decrease the number of multivolume data sets in use...


--
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: SMTP and attachements

[Paul Gilmartin]

On Sun, 19 Feb 2012 00:59:15 -0500, Scott Ford wrote:
>
>A little more information would be helpfulfrom Z/os to ? Why not FTP ?
> 
It's possible the sender has no account on the recipient's system and
vice-versa.

>On Feb 18, 2012, at 11:32 PM, Munif Sadek wrote:
>>
>> Please point me in the right direction.. I am trying to send a small VB, 
>> LRECL >500 bytes file as an attachment via SMTP from my  z/OS 1.13 without 
>> much success..
>>
>> is it possible? any working smaple?
>> 
Use TSO TRANSMIT with the output to a data set.  Attach that.
Reverse the process at the receiving end.  If SMTP still corrupts
it, zip the TRANSMIT output and attach that.  This is the
format used successfully by cbttape.org.

Have you looked into XMITIP?:

http://www.lbdsoftware.com/xmitip.html

-- gil

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