Re: google groups

[Elardus Engelbrecht]

Ed Gould wrote:

>I have had a problem with the person responsible for the list for about 9 
months (approximately). i think by their non answer they are stumped. Or else 
they tossed the issue in the bit bucket (take your pick).

bit bucket. file 13. /dev/null

;-D

>If its really bothering you you can read the the group online using John 
McGowns's instructions.

Watch out: It is John McKown!
He'll put a Gown over your head! ;-D ;-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[R.S.]

Clark Morris pisze:
[...]

The second is the question of APF authorization.  I believe that one
of the longer term goals should be to remove the need for APF
authorization from all utilities where at all possible.  


Agreed, 100%.

However there APF for *trusted* programs is nothing bad. I strongly 
believe IBM that IEBCOPY does not have any backdoors and is not 
dangerous. I also trust IBM when they say "run JES2 TRUSTED" (in terms 
of STARTED class).

I would not give APF or TRUSTED for consultant's homegrown tool.
It is worth to remember that APF does not mean that program is dangeours 
 and powerful. No, that means that program is allowed to be powerful 
and dangerous. In other words - if we trust the code of the program 
(backdoor and error free) then APF is not a problem.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

$JESX000 JOBCLASS SUPPLIED WAS INVALID CLASS B USED

[Arturo]

Could someone please tell me how I can find what is causing the system is 
changing the job class on my job from Class=A to B as shown in the Subject. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: $JESX000 JOBCLASS SUPPLIED WAS INVALID CLASS B USED

[Arturo]

just in case here is a screen print of the job card and initiators.. 

 // MSGLEVEL=(1,1),MSGCLASS=Q,CLASS=A,NOTIFY=&SYSUID  

--- Initiators
-DEVICE-ACT--STATUSINITCLAS-
   4 INIT 4   INACTIVE   F
   5 INIT 5   INACTIVE   A
   6 INIT 6   INACTIVE   A
   7 INIT 7   INACTIVE   S
   8 INIT 8   INACTIVE   S
   9 INIT 9   INACTIVE   P
  10 INIT 10 INACTIVE   Z

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RMM

[Arturo A. Arca]

Thank you. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: $JESX000 JOBCLASS SUPPLIED WAS INVALID CLASS B USED

[Rob Scott]

You have a installation written JES exit that is doing this - check with your 
sysprogs 


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

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Arturo
Sent: 08 April 2010 11:21
To: IBM-MAIN@bama.ua.edu
Subject: $JESX000 JOBCLASS SUPPLIED WAS INVALID CLASS B USED

Could someone please tell me how I can find what is causing the system is 
changing the job class on my job from Class=A to B as shown in the Subject. 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: transferring files between zos's

[Terri E Shaffer]

You can always XMIT the sequential DFDSS file to an OUTDSN and then FTP in FB 
80 mode bin.

Then do a receive inda(/) on a 3.4 screen

Thanks

Ms. Terri E. Shaffer 
terri.e.shaf...@jpmchase.com
Engineer
J.P.Morgan Chase & Co.
GTI DCT ECS Core Services zSoftware Group / Emerging Technologies 
Office: # 614-213-3467
Cell: # 412-519-2592 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
McKown, John
Sent: Wednesday, April 07, 2010 3:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: transferring files between zos's

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tim Brown
> Sent: Wednesday, April 07, 2010 1:20 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: transferring files between zos's
> 
> DFDSS can dump all files with say myqual.*.** to a seq dataset.
> I want the resulting file be ftped to another z/os for loading.
> 
> Bascially can a dfdss backup be transferred and reversed at 
> destination
> without having to use sneaker net and tapes.
> 
> Tim Brown

Yes, it can. But it is easiest if you take the DFDSS output file and use 
AMATERSE on it. This makes it into a FB/1024 dataset, which is very simple to 
ftp as BINARY, even if it "passes through" a non-z intermediate node. If you 
are going from z/OS directly to z/OS, then use MODE B.

BINARY
MODE B
PUT DFDSS.FILE 

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
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

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mary Anne Matyaz
> 
> I know this post is probably going to be met with a lot of angst, but
I've
> debated it a good bit and decided I need to warn people.
> 
> z/OS 1.11 has been the toughest migration we have done in like 9-10
years.
> [ snip ]

>From which release are you migrating?

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: $JESX000 JOBCLASS SUPPLIED WAS INVALID CLASS B USED

[Lizette Koehler]

If you have a product from DTS Software called EASYEXIT, it could do this.

You might have a submit exit (IKJEFT10???) that could do this.

If you have Thruput Manager, it might do this.

There could be a JES2 exit

Or there might be a converter exit.

Check with your SYSPROGs and see if they can help.

Lizette



> Arturo Wrote:
> 
> Could someone please tell me how I can find what is causing the system
> is
> changing the job class on my job from Class=A to B as shown in the
> Subject.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Angel-Luis Dominguez]

We use this as first step. If the file exits, it is deleted. If don't exits, 
RC=0 in 
the same way.

//PASOBOR  EXEC PGM=IEFBR14 
//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,  
//   SPACE=(1,1),   
//   DSN=USTS.U0Z72B6..   

Regards

Angel Luis Domínguez
sysprog - Spain

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Mary Anne Matyaz]

Good thought John. We do maintenance every two months. So we came from 
1.10 PUT0909 to 1.11 PUT0911. A huge jump, I know. ;) 

Mary Anne 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Console's behaviour when no paths available

[Barbara Nitz]

>Barbara, I share your pain. We had a similar failure because of a
>hardware failure in the console device itself. We were able to get the
>console offline by re-directing all its messages to another console.
>After repairs, we got it back online and active as a console with nary a
>problem. You can find the redirection mechanism under the CONTROL
>command in the Operator's Guide.

Thanks Rick.

Well, I was told that IBM assumes it was 'a network problem' (and not 
something in the OSA card itself) that caused the channel control check to be 
presented. IBM then took the cop-out and said that to be 100% sure they will 
need to have a trace active in the OSA card that needs to get stopped within 
5 minutes after the problem occuring. 

Never mind that IBM does not tell us *how* to detemine that it was this 
problem and how to stop the trace in the time window, especially at 
o:dark:30. So much for finding the *cause* of the problem.

None of this addresses the bad recovery part in commtask that I alluded to 
yesterday. Something must have been real screwy: This morning we found out 
that the console in question was still stopped. When I went there I saw that it 
was showing messages from the time of the actual first I/O error. That console 
was shown as COND=A with an online UCB and NBUF=0 (indicating no 
messages queued) on a D C right before I went there.

I typed the standard wake-up command "D T". This resulted in the emulation 
session terminating, reconnecting immediately and showing me a completely 
empty screen. Well, it prompted me for logon at the bottom (which fits with 
the last thing seen in log, namely logoff forced by some IEECV module 
yesterday morning when my colleague had done the vary online command that 
relieved the wto buffer shortage). The first message then shown on the 
console was current. There is a huge gap in messages presented to the 
consoles!

Has anyone seen consoles (after console restructure) in state cond=a with no 
messages actually on the screen and commtask not even attempting to queue 
messages there? 
What good is a console that you can't rely on?

okay, back into my corner, stop ranting.
Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Paul Gilmartin]

On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote:
>
>The second is the question of APF authorization.  I believe that one
>of the longer term goals should be to remove the need for APF
>authorization from all utilities where at all possible.  The
>requirement that IEBCOPY be APF authorized probably should have been
>removed 20 - 30 years ago since a competitive product seems to be able
>to do without it.  ...
>
That provokes a very interesting sequence of questions:

o Is that competitive product interface and data compatible with
  IEBCOPY?

o If so, can it be used as a substitute for IEBCOPY with SMP/E?

o If so, can SMP/E be run without APF authority (provided the user
  sidesteps the S99WTDSN entanglement)?

o If so, can the installation specify UACC(READ) for all the SMP/E
  facility classes with confidence that there is no threat to
  system integrity?

If the answers are respectively yes, yes, yes, no, then there is
a gaping security hole that needs to be plugged.  No unauthorized
program, regardless of the provenance of the code (IBM, customer,
ISV, or any mixture) should pose a threat to system integrity.
(Isn't that IBM's policy position?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[R.S.]

Paul Gilmartin pisze:

On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote:

The second is the question of APF authorization.  I believe that one
of the longer term goals should be to remove the need for APF
authorization from all utilities where at all possible.  The
requirement that IEBCOPY be APF authorized probably should have been
removed 20 - 30 years ago since a competitive product seems to be able
to do without it.  ...


That provokes a very interesting sequence of questions:

o Is that competitive product interface and data compatible with
  IEBCOPY?

o If so, can it be used as a substitute for IEBCOPY with SMP/E?

o If so, can SMP/E be run without APF authority (provided the user
  sidesteps the S99WTDSN entanglement)?

o If so, can the installation specify UACC(READ) for all the SMP/E
  facility classes with confidence that there is no threat to
  system integrity?

If the answers are respectively yes, yes, yes, no, then there is
a gaping security hole that needs to be plugged.  No unauthorized
program, regardless of the provenance of the code (IBM, customer,
ISV, or any mixture) should pose a threat to system integrity.
(Isn't that IBM's policy position?)


Do we know that the APAR is related to APF authorization of GIMSMP?
Why do we consider IEBCOPY? Is IEBCOPY engaged in any way in the APAR? 
Do we know that?


BTW: I know that APF program cannot call other program out of APF 
library. However in this case we consider the opposite scenario: Can 
non-APF program call APF-one?  If so, then GIMSPE may be unathorized 
with no changes to IEBCOPY authorization. Is my assumption correct?


BTW2: I can imagine APAR classified as integrity for unauthorized 
program and this does not break any integrity statement. Just matter of 
"integrity" definition.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Paul Gilmartin]

On Thu, 8 Apr 2010 15:17:03 +0200, R.S. wrote:
>>
>> ...   No unauthorized
>> program, regardless of the provenance of the code (IBM, customer,
>> ISV, or any mixture) should pose a threat to system integrity.
>> (Isn't that IBM's policy position?)
>
>Do we know that the APAR is related to APF authorization of GIMSMP?
>Why do we consider IEBCOPY? Is IEBCOPY engaged in any way in the APAR?
>Do we know that?
>
All irrelevant (see last paragraph below).  But, empirically, I have
run SMP/E unauthorized (inadvertently or experimentally) The problems
I encountered concerned IEBCOPY and S99WTDSN.  There might be others.

>BTW: I know that APF program cannot call other program out of APF
>library. However in this case we consider the opposite scenario: Can
>non-APF program call APF-one?  If so, then GIMSPE may be unathorized
>with no changes to IEBCOPY authorization. Is my assumption correct?
>
In that case, the otherwise authorized program executes unauthorized.
My experience (see above) confirms this.

>BTW2: I can imagine APAR classified as integrity for unauthorized
>program and this does not break any integrity statement. Just matter of
>"integrity" definition.
>
Essentially, we agree.

My understanding of IBM's integrity statement (not verbatim) is that
no unauthorized program can attain superviser state, key 0, or
otherwise escalate its privileges.  So, yes, if an unauthorized program
does this, it's pretty automatically cause for an integrity APAR for
an unauthorized program.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Kelman, Tom]

Actually, the dataset we had a problem with wasn't a VSAM dataset, but the 
situation was that the storage folks had started setting up VSAM striped 
datasets which, of course, required VSAM EF.  I've been a performance 
analyst/capacity planner for some 15 years now, so I'm no real familiar with 
the current SMS processes.  I don't know why setting up VSAM EF to stripe one 
VSAM file would have caused this.  I just know that it did.  The PS dataset in 
question had the same high level as the VSAM dataset they had striped.

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of R.S.
> Sent: Wednesday, April 07, 2010 10:43 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> Kelman, Tom pisze:
> > Just a warning about using SPACE=(TRK,0).  We had a job that used that
> and it all of a sudden started getting abends with a message that there
> was no space defined.  Our storage folks had just set up SMS for VSAM
> Extended for that specific group of datasets.  It appears that once you do
> that it closes a hole that allowed the SPACE=(TRK,0) specification.  We
> had to change it to SPACE=(TRK,1) which worked.
> 
> I did not consider VSAM, especially VSAM EF. My habit is to use IDCAMS
> when manipulating VSAM. Of course it is allowed to use IDCAMS for
> nonVSAM datasets and DISP=(MOD,DELETE) for VSAM ones, but I just didn't
> try to specify TRK,0 for VSAM EF.
> 
> Honestly I've been using TRK,1 for years (just a habit). It seems it's
> more flexible. ;-)
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> --
> BRE Bank SA
> ul. Senatorska 18
> 00-950 Warszawa
> www.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.2009 r. kapita zakadowy BRE Banku SA (w
> caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj
> warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ
> z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika
> 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w
> podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Tom Marchant]

On Wed, 7 Apr 2010 22:49:03 +, Ted MacNEIL wrote:

>Customer: How do we configure this to plug the hole?
>IBM: For system integrity reasons, we can't tell you.
>Customer: What would happen if we configure it incorrectly?
>IBM: For system integrity reasons, we can't tell you.
>Customer: Can you at least tell us what function(s) we should protect?
>IBM: For system integrity reasons, we can't tell you.

Your rant is a bit over the top, Ted.  Did you bother to read 
Information APAR II14489 that Kurt Quackenbush posted?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Non-SMS-managed LOGR offload data sets

[Arthur Gutowski]

On Wed, 7 Apr 2010 03:48:32 -0500, Barbara Nitz  
wrote:

>Unscientific survey:
>
>How many of you use truly non-SMS-managed LOGR datasets? As in: Using
>the two model data sets and an IEFDB401 exit that specifies the DALLIKE text
>unit?

All SMS-managed, AFAIK.  No IEFDB401 exit.

>How many of you 'share' a pool of DASD (for LOGR data sets) in two SMSs?

Nope, separate SMSPlexen for separate managed DASD.

>(Don't ask me why I am asking.)

Too late, apparently (the trouble with daily digest), but the thread went right 
where I did.  We hear 'too much' as well, but I don't argue - we are all in the 
same boat (where's my paddle?).

I entertained Mark's solution, but I am nervous with production logstreams.  
Dump pools aren't critical, but we have enough trouble with logstream pools as 
it is (our sandbox went casters-up yesterday, and because I was playing with 
CF MAINTMODE, I thought it was me, at first).  I don't want to further 
frustrate our storage managers with an unsupported, albeit workable, tactical 
fix.  We'll just deal with it until we can merge SMS'.

Regards,
Art Gutowski
Ford Motor Company

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Michel Castelein]

On Thu, 8 Apr 2010 06:35:15 -0500, Angel-Luis Dominguez 
 wrote:

>We use this as first step. If the file exits, it is deleted. If don't exits, 
>RC=0 in
>the same way.
>
>//PASOBOR  EXEC PGM=IEFBR14
>//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
>//   SPACE=(1,1),
>//   DSN=USTS.U0Z72B6..
>
>Regards
>
>Angel Luis Domínguez
>sysprog - Spain
>

BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).

If the data set does not already exist, DISP=MOD is processed as DISP=NEW, 
which causes I/O to be initiated to access the VTOC and allocate disk space, 
space that will be unallocated at the end of the step.

Using IDCAMS is more performant:
//PASOBOR EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  LISTCAT ENTRY(USTS.U0Z72B6..)
  IF LASTCC=0 THEN DELETE USTS.U0Z72B6..
  SET MAXCC=0
/*
//

Regards,

Michel Castelein
z/OS instructor

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Greg Shirey]

Why?  If I run: 

//DPC088IF JOB (DPC088,JDG),'IEFBR14',CLASS=A,MSGCLASS=X,   
// MSGLEVEL=(1,1),NOTIFY=DPC088   
//EXEC PGM=IEFBR14  
//SYSPRINT  DD SYSOUT=* 
//SYSOUTDD SYSOUT=* 
//TEST  DD DSN=DPC088.TEST.TEST.ALLOC,DISP=(MOD,DELETE,DELETE), 
// SPACE=(1,1)  

I see: 

IGD101I SMS ALLOCATED TO DDNAME (TEST)
DSN (DPC088.TEST.TEST.ALLOC  )
STORCLAS (TSOSC) MGMTCLAS () DATACLAS (DEFAULT)   
VOL SER NOS= TSO002   

IEF142I DPC088IF - STEP WAS EXECUTED - COND CODE    


Greg Shirey
Ben E. Keith Co. 


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Michel Castelein
Sent: Thursday, April 08, 2010 9:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION


BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Paul Gilmartin]

On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:
>
>>//PASOBOR  EXEC PGM=IEFBR14
>>//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
>>//   SPACE=(1,1),
>>//   DSN=USTS.U0Z72B6..
>
>BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
>
Why?  In my opinion Simpler Is Better.  What advantage do you
see in using the more complicated form?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Kelman, Tom]

You see the SMS allocation because if the dataset doesn't exist the JCL
you've specified will allocate it as a new dataset and then delete it.
If it does exist it will be allocated at and old (mod) dataset and then
deleted.  In either case you should see this message later in the
JESYSMSG. 

IGD105I DPC088.TEST.TEST.ALLOC  DELETED,
DDNAME=TEST

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Greg Shirey
> Sent: Thursday, April 08, 2010 9:15 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> Why?  If I run:
> 
> //DPC088IF JOB (DPC088,JDG),'IEFBR14',CLASS=A,MSGCLASS=X,
> // MSGLEVEL=(1,1),NOTIFY=DPC088
> //EXEC PGM=IEFBR14
> //SYSPRINT  DD SYSOUT=*
> //SYSOUTDD SYSOUT=*
> //TEST  DD DSN=DPC088.TEST.TEST.ALLOC,DISP=(MOD,DELETE,DELETE),
> // SPACE=(1,1)
> 
> I see:
> 
> IGD101I SMS ALLOCATED TO DDNAME (TEST)
> DSN (DPC088.TEST.TEST.ALLOC  )
> STORCLAS (TSOSC) MGMTCLAS () DATACLAS (DEFAULT)
> VOL SER NOS= TSO002
> 
> IEF142I DPC088IF - STEP WAS EXECUTED - COND CODE 
> 
> 
> Greg Shirey
> Ben E. Keith Co.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Michel Castelein
> Sent: Thursday, April 08, 2010 9:07 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> 
> BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Thursday, April 08, 2010 9:20 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION

On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:
>
>>//PASOBOR  EXEC PGM=IEFBR14
>>//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
>>//   SPACE=(1,1),
>>//   DSN=USTS.U0Z72B6..
>
>BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
>
Why?  In my opinion Simpler Is Better.  What advantage do you
see in using the more complicated form?



Gil, try it and let us know how you get around paying your syntax.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Kelman, Tom]

Paul,

I was surprised.  I thought the type of space (TRK, CYL, etc.) was
required.  I just tried allocating a dataset using SPACE=(1,1), and it
does allocate 1 track.  However, personally I still prefer putting "TRK"
in the SPACE parameter.  It's called documentation, and there are
probably others, notably application programmers, who don't realize that
SPACE=(1,1) will allocate 1 track.

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, April 08, 2010 9:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:
> >
> >>//PASOBOR  EXEC PGM=IEFBR14
> >>//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
> >>//   SPACE=(1,1),
> >>//   DSN=USTS.U0Z72B6..
> >
> >BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
> >
> Why?  In my opinion Simpler Is Better.  What advantage do you
> see in using the more complicated form?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

SYSPLEX/CFRM Couple dataset(s) relationship

[Mark Jacobs]

At our last DR exercise we had an incorrect CPU serial number in our 
CFRM policy which resulted in a failure in our IPL. We fixed the CFRM 
policy and re-wrote it replacing the incorrect policy (same policy name).


When we re-ipled, the system was still looking for the CF lpar with the 
incorrect CPU serial number even though the CFRM policy with the old 
serial number wasn't in the CFRM dataset. We couldn't get the system to 
IPL until I deleted and redefined the SYSPLEX couple dataset.


Does the sysplex couple dataset retain information about the CFRM policy 
in use other than the name of the last used CFRM policy?


--
Mark Jacobs
Time Customer Service
Tampa, FL


It is impossible to make anything foolproof, because fools
are so ingenious.

 -- Robert Heinlein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Paul Gilmartin]

On Thu, 8 Apr 2010 09:15:02 -0500, Greg Shirey wrote:
>
>BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
>
>Why?  If I run:
>
>//DPC088IF JOB (DPC088,JDG),'IEFBR14',CLASS=A,MSGCLASS=X,
>// MSGLEVEL=(1,1),NOTIFY=DPC088
>//EXEC PGM=IEFBR14
>//SYSPRINT  DD SYSOUT=*
>//SYSOUTDD SYSOUT=*
>//TEST  DD DSN=DPC088.TEST.TEST.ALLOC,DISP=(MOD,DELETE,DELETE),
>// SPACE=(1,1)
>
Perhaps the same reason you allocate SYSPRINT and SYSOUT in an IEFBR14
step.  (What about SYSIN?)  Habit?  Perhaps your installation has a
different version of IEFBR14 from mine.

I used SPACE=(1,0).  I'm a minimalist.  Does thle involve less
work cleaning up the VTOC on DELETE?  But I agree, IDCAMS is
better; it avoids a job step with 3 allocations, and it avoids
creating a data set only to delete it immediately.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM-MAIN Digest - 6 Apr 2010 to 7 Apr 2010 (#2010-97)

[Jim Holloway]

Barbara Nitz wrote:
> Unscientific survey:
> 
> How many of you use truly non-SMS-managed LOGR datasets? As in: Using 
> the two model data sets and an IEFDB401 exit that specifies the DALLIKE 
text 
> unit? 

Question1 :  Ours are all SMS managed.
Question 2:  We don't share a poolfor logger datasets


Jim Holloway  - Met Life 
The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Paul Gilmartin]

On Thu, 8 Apr 2010 09:29:50 -0500, Kelman, Tom wrote:
>
>I was surprised.  I thought the type of space (TRK, CYL, etc.) was
>required.  I just tried allocating a dataset using SPACE=(1,1), and it
>does allocate 1 track.  However, personally I still prefer putting "TRK"
>in the SPACE parameter.  It's called documentation, and there are
>probably others, notably application programmers, who don't realize that
>SPACE=(1,1) will allocate 1 track.
>
Perhaps it was just Muphry's law.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Thursday, April 08, 2010 9:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION


Perhaps the same reason you allocate SYSPRINT and SYSOUT in an IEFBR14
step.  (What about SYSIN?)  Habit?  Perhaps your installation has a
different version of IEFBR14 from mine.

I used SPACE=(1,0).  I'm a minimalist.  Does thle involve less
work cleaning up the VTOC on DELETE?  But I agree, IDCAMS is
better; it avoids a job step with 3 allocations, and it avoids
creating a data set only to delete it immediately.



Seriously, I knew that you do this in ALLOC under TSO. But I've never
seen SPACE=(1,1) work in JCL. I just looked at my old 1.7 manual and as
I read it, you must code the allocation unit parm.

Uh, OK, is it assuming a block of 1 byte in this case?

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSPLEX/CFRM Couple dataset(s) relationship

[Field, Alan C.]

Mark, I don't know but we used to run into the same problem at DR until
we started defining our CFRM policy with 4 CFs. 

CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR.

I define the policies with a preflist of (CF1,CF2,CF3,CF4).

Now when we're at home or DR IPL proceeds without a hitch. 

I think I got the idea for doing this from a post on this list a few
years ago.

Alan

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Jacobs
Sent: Thursday, April 08, 2010 09:31 
To: IBM-MAIN@bama.ua.edu
Subject: SYSPLEX/CFRM Couple dataset(s) relationship

At our last DR exercise we had an incorrect CPU serial number in our 
CFRM policy which resulted in a failure in our IPL. We fixed the CFRM 
policy and re-wrote it replacing the incorrect policy (same policy
name).

When we re-ipled, the system was still looking for the CF lpar with the 
incorrect CPU serial number even though the CFRM policy with the old 
serial number wasn't in the CFRM dataset. We couldn't get the system to 
IPL until I deleted and redefined the SYSPLEX couple dataset.

Does the sysplex couple dataset retain information about the CFRM policy

in use other than the name of the last used CFRM policy?

-- 
Mark Jacobs
Time Customer Service
Tampa, FL


It is impossible to make anything foolproof, because fools
are so ingenious.

  -- Robert Heinlein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Farley, Peter x23353]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Kelman, Tom
> Sent: Thursday, April 08, 2010 10:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> Paul,
> 
> I was surprised.  I thought the type of space (TRK, CYL, etc.) was
> required.  I just tried allocating a dataset using SPACE=(1,1), and it
> does allocate 1 track.  However, personally I still prefer putting
"TRK"
> in the SPACE parameter.  It's called documentation, and there are
> probably others, notably application programmers, who don't realize
that
> SPACE=(1,1) will allocate 1 track.

Hold on there!  I resemble that remark!  I and plenty of other
application programmers aren't as ignorant as some on this list would
lead you to think.

For my own delete-before-creating steps, I successfully use SPACE=(0,0)
with no trouble at all.  YMMV, of course.

Peter


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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Greg Shirey]

Eh?  I was simply asking the same question you asked - why "should" you
code SPACE=(TRK,(1,1))?  Then I included an example showing that it
isn't necessary.  

I wasn't asking why it worked.  

Greg


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Thursday, April 08, 2010 9:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION

>
>BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
>
>Why?  If I run:
>
>//DPC088IF JOB (DPC088,JDG),'IEFBR14',CLASS=A,MSGCLASS=X,
>// MSGLEVEL=(1,1),NOTIFY=DPC088
>//EXEC PGM=IEFBR14
>//SYSPRINT  DD SYSOUT=*
>//SYSOUTDD SYSOUT=*
>//TEST  DD DSN=DPC088.TEST.TEST.ALLOC,DISP=(MOD,DELETE,DELETE),
>// SPACE=(1,1)
>
Perhaps the same reason you allocate SYSPRINT and SYSOUT in an IEFBR14
step.  (What about SYSIN?)  Habit?  Perhaps your installation has a
different version of IEFBR14 from mine.

I used SPACE=(1,0).  I'm a minimalist.  Does thle involve less
work cleaning up the VTOC on DELETE?  But I agree, IDCAMS is
better; it avoids a job step with 3 allocations, and it avoids
creating a data set only to delete it immediately.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kelman, Tom
> Sent: Thursday, April 08, 2010 9:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> Paul,
> 
> I was surprised.  I thought the type of space (TRK, CYL, etc.) was
> required.  I just tried allocating a dataset using SPACE=(1,1), and it
> does allocate 1 track.  However, personally I still prefer 
> putting "TRK"
> in the SPACE parameter.  It's called documentation, and there are
> probably others, notably application programmers, who don't 
> realize that
> SPACE=(1,1) will allocate 1 track.
> 
> Tom Kelman

SPACE=(1,1) means: "Allocate the number of tracks need to contain 1 block which 
has a blksize of 1". This is always 1 TRK. I agree that (TRK,1) is simply 
better in that it causes less confusion. As is proven by these messages.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
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

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11 - and FIXCAT Comment

[Marna WALLE]

On Wed, 7 Apr 2010 14:19:00 -0500, Mark Zelden  wrote:

>FIXCAT(
>  IBM.ProductInstall-RequiredService
>  IBM.Coexistence.z/OS.V1R11
>  ).
>
>Don't ask me why I found some 1.11 PTFs that were mentioned in the
>PSP buckets coded with "IBM.Coexistence.z/OS.V1R11" instead of
>"IBM.ProductInstall-RequiredService".  Unless I'm wrong, fixes for 1.11
>shouldn't have coexistence for 1.11 tags.  Maybe the person who coded
>these PTFs didn't understand FIXCAT (no, I didn't open a PMR on this).
>
>Mark

Mark,
Coexistence maintenance can also have the
"IBM.ProductInstall-RequiredService" FIXCAT associated with it.  It depends
on particular APAR, and there are several in that category.  

Also, I've seen at least one APAR where there was coexistence PTF for that
release's coexistence!  For example, that may be appropriate when a change
in R11 was necessary to make the toleration on lower releases simpler and
that R11 code hadn't been put there originally :).  Remember, the FIXCAT
applies to all PTFs for that APAR, and we cannot selectively have the FIXCAT
for some PTFs on an APAR and not for others.

Hope this helps explain what you may be seeing,
-Marna WALLE
z/OS System Build and Install

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Elardus Engelbrecht]

Thompson, Steve wrote:
>Seriously, I knew that you do this in ALLOC under TSO. But I've never
seen SPACE=(1,1) work in JCL. I just looked at my old 1.7 manual and as I 
read it, you must code the allocation unit parm.

>Uh, OK, is it assuming a block of 1 byte in this case?


I decided to do this (I changed DISP so I can see afterwards on =3.4) just to 
see what happens:


//STEP1  EXEC PGM=IEFBR14
//SYSUT4   DD DSN=A,DISP=(,CATLG),SPACE=(0,0)

Organization  . . . : PS
Record format . . . : ? 
Record length . . . : 0 
Block size  . . . . : 0 
1st extent tracks . : 0 
Secondary blocks  . : 0 

//STEP1  EXEC PGM=IEFBR14
//SYSUT4   DD DSN=B,DISP=(,CATLG),SPACE=(1,1) 

Organization  . . . : PS
Record format . . . : ? 
Record length . . . : 0 
Block size  . . . . : 0 
1st extent tracks . : 1 
Secondary blocks  . : 0

//STEP1  EXEC PGM=IEFBR14 
//SYSUT4   DD DSN=C,DISP=(,CATLG),SPACE=(1,0)

Organization  . . . : PS 
Record format . . . : ?  
Record length . . . : 0  
Block size  . . . . : 0  
1st extent tracks . : 0  
Secondary blocks  . : 0  

Not practical results, but go figure... ;-D

Groete / Greetings
Elardus Engelbrecht 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Paul Gilmartin]

On Thu, 8 Apr 2010 10:39:32 -0400, Farley, Peter x23353 wrote:
>>
>> in the SPACE parameter.  It's called documentation, and there are
>> probably others, notably application programmers, who don't realize
>that
>> SPACE=(1,1) will allocate 1 track.
>
The necessary documentation is all in the JCL RM.  Has been long
before and after 1.7.

>Hold on there!  I resemble that remark!  I and plenty of other
>application programmers aren't as ignorant as some on this list would
>lead you to think.
>
>For my own delete-before-creating steps, I successfully use SPACE=(0,0)
>with no trouble at all.  YMMV, of course.
>
I will habitually avoid the delete-before-creating step with:

//CREATE  DD  DISP=(MOD,CATLG),UNIT=SYSALLDA,SPACE=...,
//  DSN=...
//*
//SYSUT2  DD  DISP=SHR,DSN=*.CREATE,VOL=REF=*.CREATE.

(Provided I trust the attributes of the existing data set.)
(Typed from memory; untested.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSPLEX/CFRM Couple dataset(s) relationship

[Vernooij, CP - SPLXM]

"Mark Jacobs"  wrote in message
news:<4bbde8bb.6070...@custserv.com>...
> At our last DR exercise we had an incorrect CPU serial number in our 
> CFRM policy which resulted in a failure in our IPL. We fixed the CFRM 
> policy and re-wrote it replacing the incorrect policy (same policy
name).
> 
> When we re-ipled, the system was still looking for the CF lpar with
the 
> incorrect CPU serial number even though the CFRM policy with the old 
> serial number wasn't in the CFRM dataset. We couldn't get the system
to 
> IPL until I deleted and redefined the SYSPLEX couple dataset.
> 
> Does the sysplex couple dataset retain information about the CFRM
policy 
> in use other than the name of the last used CFRM policy?
> 
> -- 
> Mark Jacobs

Yes, the CDS contains a number of slots to hold defined policies and 1
slot for the "active" policy. This one is used at IPL and can only be
changed by activating a policy from on of the defined policies.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Vernooij, CP - SPLXM]

"Elardus Engelbrecht"  wrote in message
news:...
> Thompson, Steve wrote:
> >Seriously, I knew that you do this in ALLOC under TSO. But I've never
> seen SPACE=(1,1) work in JCL. I just looked at my old 1.7 manual and
as I 
> read it, you must code the allocation unit parm.
> 
> >Uh, OK, is it assuming a block of 1 byte in this case?
> 
> 
> I decided to do this (I changed DISP so I can see afterwards on =3.4)
just to 
> see what happens:
> 
> 
> //STEP1  EXEC PGM=IEFBR14
> //SYSUT4   DD DSN=A,DISP=(,CATLG),SPACE=(0,0)
> 
> Organization  . . . : PS
> Record format . . . : ? 
> Record length . . . : 0 
> Block size  . . . . : 0 
> 1st extent tracks . : 0 
> Secondary blocks  . : 0 
> 
> //STEP1  EXEC PGM=IEFBR14
> //SYSUT4   DD DSN=B,DISP=(,CATLG),SPACE=(1,1) 
> 
> Organization  . . . : PS
> Record format . . . : ? 
> Record length . . . : 0 
> Block size  . . . . : 0 
> 1st extent tracks . : 1 
> Secondary blocks  . : 0
> 
> //STEP1  EXEC PGM=IEFBR14 
> //SYSUT4   DD DSN=C,DISP=(,CATLG),SPACE=(1,0)
> 
> Organization  . . . : PS 
> Record format . . . : ?  
> Record length . . . : 0  
> Block size  . . . . : 0  
> 1st extent tracks . : 0  
> Secondary blocks  . : 0  
> 
> Not practical results, but go figure... ;-D
> 
> Groete / Greetings

No figure at all: as explained, the first number is the blocklength and
the second is the number of blocks. Requesting 1 block gives 1 track,
requesting 0 blocks gives 0 tracks.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11 - and FIXCAT Comment

[Mark Zelden]

On Thu, 8 Apr 2010 09:45:50 -0500, Marna WALLE  wrote:

>On Wed, 7 Apr 2010 14:19:00 -0500, Mark Zelden  wrote:
>
>>FIXCAT(
>>  IBM.ProductInstall-RequiredService
>>  IBM.Coexistence.z/OS.V1R11
>>  ).
>>
>>Don't ask me why I found some 1.11 PTFs that were mentioned in the
>>PSP buckets coded with "IBM.Coexistence.z/OS.V1R11" instead of
>>"IBM.ProductInstall-RequiredService".  Unless I'm wrong, fixes for 1.11
>>shouldn't have coexistence for 1.11 tags.  Maybe the person who coded
>>these PTFs didn't understand FIXCAT (no, I didn't open a PMR on this).
>>
>>Mark
>
>Mark,
>Coexistence maintenance can also have the
>"IBM.ProductInstall-RequiredService" FIXCAT associated with it.  It depends
>on particular APAR, and there are several in that category.
>
>Also, I've seen at least one APAR where there was coexistence PTF for that
>release's coexistence!  For example, that may be appropriate when a change
>in R11 was necessary to make the toleration on lower releases simpler and
>that R11 code hadn't been put there originally :).  Remember, the FIXCAT
>applies to all PTFs for that APAR, and we cannot selectively have the FIXCAT
>for some PTFs on an APAR and not for others.
>
>Hope this helps explain what you may be seeing,
>-Marna WALLE
>z/OS System Build and Install


Hi Marna,

Thanks.  Yes, that explain the coexistence part.  But shouldn't a PTF identified
in the PSP buckets also  be coded with ""IBM.ProductInstall-RequiredService"?  
I thought that was the FIXCAT category that was to replace the PSP
tool.  I initially installed all that "required" service and then later on I
actually
read the PSP buckets (just like "the old days") and found I was missing a 
PTF that was coded with IBM.Coexistence.z/OS.V1R11.

So moving forward, I will always do both to get the PSP identified maintenance,
but I wasn't sure if this was a mistake or WAD. 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSPLEX/CFRM Couple dataset(s) relationship

[Mark Zelden]

Skip has talked about this in the past and in SHARE sessions.  

What we have done for years is use a different "newly formatted"  sysplex
couple and CFRM couple data sets that we IPL with during DR.  This has
also been discussed.

Regards,

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


On Thu, 8 Apr 2010 09:39:36 -0500, Field, Alan C.
 wrote:

>Mark, I don't know but we used to run into the same problem at DR until
>we started defining our CFRM policy with 4 CFs.
>
>CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR.
>
>I define the policies with a preflist of (CF1,CF2,CF3,CF4).
>
>Now when we're at home or DR IPL proceeds without a hitch.
>
>I think I got the idea for doing this from a post on this list a few
>years ago.
>
>Alan
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>Behalf Of Mark Jacobs
>Sent: Thursday, April 08, 2010 09:31
>To: IBM-MAIN@bama.ua.edu
>Subject: SYSPLEX/CFRM Couple dataset(s) relationship
>
>At our last DR exercise we had an incorrect CPU serial number in our
>CFRM policy which resulted in a failure in our IPL. We fixed the CFRM
>policy and re-wrote it replacing the incorrect policy (same policy
>name).
>
>When we re-ipled, the system was still looking for the CF lpar with the
>incorrect CPU serial number even though the CFRM policy with the old
>serial number wasn't in the CFRM dataset. We couldn't get the system to
>IPL until I deleted and redefined the SYSPLEX couple dataset.
>
>Does the sysplex couple dataset retain information about the CFRM policy
>
>in use other than the name of the last used CFRM policy?
>
>--
>Mark Jacobs
>Time Customer Service
>Tampa, FL
>
>
>It is impossible to make anything foolproof, because fools
>are so ingenious.
>
>  -- Robert Heinlein
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Walt Farrell]

On Wed, 7 Apr 2010 18:36:15 -0400, Don Williams  wrote:

>APF authorization or superuser authority is the keys to kingdom. Any program
>granted those privileges must be very carefully designed, written, and
>tested, and tested, and  with paranoia. If there were granular types of
>authorization, it seems that you to should be able only grant a program the
>authority it needs to get its job done. Of course, it could too granular so
>that you're spending all your time trying to figure out what needs to be
>granted. However, somewhere between those two extremes there is bound to be
>a good compromise. Pinch me, I must be dreaming.

It seems to be true that there are selected functions (or sub-functions)
that it would be safe to allow in some way other than by granting full APF
authorization.  

However, in the research we did it was not clear how to grant them to
programs, rather than to the users running those programs.  Nor was it clear:
(a) how to do so in a way that did not impose undue administrative burdens; 
(b) how to allow vendors to describe to system administrators which granular
authorities their programs would need; 
(c) How to allow the administrators to discover which granular authorities
any particular program might need.

Additionally, it is not clear whether the set of functions/sub-functions for
which we could allow granular authorization is large enough to actually
allow removal of AC(1) from a significant number of programs. 

The real issue, I believe, is that there is a (so far) relatively small set
of functions amenable to granular authorization and a much larger set of
functions for which usage, even if authorized in a granular manner, could
allow privilege escalation and eventual acquisition of full authorization.

So at the moment and for the foreseeable future it must remain only a nice
dream, I'm afraid.

-- 
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Ted MacNEIL]

>  LISTCAT ENTRY(USTS.U0Z72B6..)
>  IF LASTCC=0 THEN DELETE USTS.U0Z72B6..
>  SET MAXCC=0

Simpler/shorter:

 DELETE USTS.U0Z72B6..
 IF LASTCC<9 THEN  SET MAXCC=0

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Ted MacNEIL]

>I just tried allocating a dataset using SPACE=(1,1), and it does allocate 1 
>track.

Actually, there is the old form of JCL, where you are allocating in blocks, 
rather than tracks/cylinders.

Check the JCL Reference.

BTW, you are asking for one byte blocks, and only one of them.
But, the minimum dataset size is one track for (E)CKD.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Ted MacNEIL]

>>> SPACE=(1,1) will allocate 1 track.
>
>The necessary documentation is all in the JCL RM.
>Has been long before and after 1.7.

Since at least 1981, when I first learned JCL.
With SMS, the allocation units were changed to allow M/K to be tacked on, so 
that (in theory) apps-types could think in records, rather than in device 
dependent terms.

I've never seen it catch on though.
Most JCL I've seen still talks in TRK & CYL, regardless of who 
writes/copies/steals it.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SYSPLEX/CFRM Couple dataset(s) relationship

[Mark Jacobs]

On 04/08/10 11:07, Mark Zelden wrote:

Skip has talked about this in the past and in SHARE sessions.

What we have done for years is use a different "newly formatted"  sysplex
couple and CFRM couple data sets that we IPL with during DR.  This has
also been discussed.

Regards,

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

   


That's what we do at DR also. I was wondering if the first IPL with the 
incorrect CFRM policy 'corrupted' the sysplex couple dataset in such a 
way that it didn't re-read the CFRM couple dataset for the policy which 
was rewritten with the correct CPU serial number.


Mark Jacobs



On Thu, 8 Apr 2010 09:39:36 -0500, Field, Alan C.
  wrote:

   

Mark, I don't know but we used to run into the same problem at DR until
we started defining our CFRM policy with 4 CFs.

CF1 and CF2 are the ones at home. CF3 and CF4 are the ones at DR.

I define the policies with a preflist of (CF1,CF2,CF3,CF4).

Now when we're at home or DR IPL proceeds without a hitch.

I think I got the idea for doing this from a post on this list a few
years ago.

Alan

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Mark Jacobs
Sent: Thursday, April 08, 2010 09:31
To: IBM-MAIN@bama.ua.edu
Subject: SYSPLEX/CFRM Couple dataset(s) relationship

At our last DR exercise we had an incorrect CPU serial number in our
CFRM policy which resulted in a failure in our IPL. We fixed the CFRM
policy and re-wrote it replacing the incorrect policy (same policy
name).

When we re-ipled, the system was still looking for the CF lpar with the
incorrect CPU serial number even though the CFRM policy with the old
serial number wasn't in the CFRM dataset. We couldn't get the system to
IPL until I deleted and redefined the SYSPLEX couple dataset.

Does the sysplex couple dataset retain information about the CFRM policy

in use other than the name of the last used CFRM policy?

--
Mark Jacobs
Time Customer Service
Tampa, FL


It is impossible to make anything foolproof, because fools
are so ingenious.

  -- Robert Heinlein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

   



--
Mark Jacobs
Time Customer Service
Tampa, FL


It is impossible to make anything foolproof, because fools
are so ingenious.

 -- Robert Heinlein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Steve Comstock]

Thompson, Steve wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Thursday, April 08, 2010 9:20 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION

On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:

//PASOBOR  EXEC PGM=IEFBR14
//D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
//   SPACE=(1,1),
//   DSN=USTS.U0Z72B6..

BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).


Why?  In my opinion Simpler Is Better.  What advantage do you
see in using the more complicated form?



Gil, try it and let us know how you get around paying your syntax.

Regards,
Steve Thompson


Nothing wrong with the syntax: it says allocate enough space
to hold 1 block of 1 byte long; the system will figure out
that can fit on one track.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* z/OS application programmer training
  + Instructor-led on-site classroom based classes
  + Course materials licensing
  + Remote contact training
  + Roadshows
  + Course development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Steve Comstock
Sent: Thursday, April 08, 2010 10:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JCL QUESTION

Thompson, Steve wrote:
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, April 08, 2010 9:20 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: JCL QUESTION
> 
> On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:
>>> //PASOBOR  EXEC PGM=IEFBR14
>>> //D1 DD   DISP=(MOD,DELETE),UNIT=SYSALLDA,
>>> //   SPACE=(1,1),
>>> //   DSN=USTS.U0Z72B6..
>> BTW, SPACE=(1,1) should be SPACE=(TRK,(1,1)).
>>
> Why?  In my opinion Simpler Is Better.  What advantage do you
> see in using the more complicated form?
> 
> 
> 
> Gil, try it and let us know how you get around paying your syntax.
> 
> Regards,
> Steve Thompson

Nothing wrong with the syntax: it says allocate enough space
to hold 1 block of 1 byte long; the system will figure out
that can fit on one track.


This was just a case of tunnel vision. I knew about block size
allocation. But my brain rebelled at 0 or 1. Then I started thinking...

This is what you get when you work on data xfer software and are
dependant on how JCL and SVC99 Text units interplay and then you are
working on some special problem...

The joys of tunnel vision.

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Console's behaviour when no paths available

[Tony Harminc]

On 8 April 2010 08:19, Barbara Nitz  wrote:

> Well, I was told that IBM assumes it was 'a network problem' (and not
> something in the OSA card itself) that caused the channel control check to be
> presented. IBM then took the cop-out and said that to be 100% sure they will
> need to have a trace active in the OSA card that needs to get stopped within
> 5 minutes after the problem occuring.
>
> Never mind that IBM does not tell us *how* to detemine that it was this
> problem and how to stop the trace in the time window, especially at
> o:dark:30. So much for finding the *cause* of the problem.

Wouldn't it be by definition a hardware problem in the OSA card if a
"network problem" is capable of causing a channel control check? My
reading of the definition of Channel Control Check in the Principles
of Operation is that it is a machine malfunction that cannot be caused
by external data or conditions. Perhaps you should ask them if the OSA
card has been granted a deviation from the POO; they take this stuff
fairly seriously.

I'm also surprised that the machine didn't call home about this kind
of hardware problem. Perhaps they already have logs and such, but the
wrong people have them.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Elardus Engelbrecht]

Vernooij, CP wrote:
>No figure at all: as explained, the first number is the blocklength and the 
second is the number of blocks. Requesting 1 block gives 1 track, requesting 0 
blocks gives 0 tracks.

Of course. Not that difficult to figure it out.

You put it better in words than me. Thanks. Kees, please continue posting 
your valuable and interesting post here. 

As Barbara very nicely said, I will go back to my corner and stop ranting... ;-D

Take care to all!
 
Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Guy Gardoit]

Just wondering why you choose to use PUT levels rather than RSU levels.  We
are converting our remaining LPARs from 1.10 to 1.11 (sandbox and 3
production/testing LPARs already converted) on 4/18 at RSU0912+HIPERs+PRP.
Haven't experienced any problems with our 3 so far.  Next maintenance cycle
will be in July, but it will be quarterly RSU1003+HIPERs+PRP.   I've found
using a policy of staying at currentquarterlyRSU-1 works pretty well for us
anyway.



On Thu, Apr 8, 2010 at 4:45 AM, Mary Anne Matyaz wrote:

> Good thought John. We do maintenance every two months. So we came from
> 1.10 PUT0909 to 1.11 PUT0911. A huge jump, I know. ;)
>
> Mary Anne
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

CA-Spool Message ESF735

[John P Kalinich]

CA-Spool 11.5 is issuing message "ESF735  CA Health Checker Initialization
failed with RC=40" and it is not documented.  Any ideas?

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Mary Anne Matyaz]

I don't really have a great answer for that Greg. Mainly I guess because this 
process was set up prior to RSU's. :)  But seriously, sometimes a PTF will be 
in 
PUT1001 but RSU1002. RSU's only save about 20%, IIRC, and it seems like half 
the time some schmuck will want a PTF on that wasn't in the RSU. 

But I'm open to debate...go ahead, change my mind! :) 

Mary Anne 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA-Spool Message ESF735

[Staller, Allan]

Contact CA? (if there is still anyone left to answer the phone)

I would guess this is enabled by some component of CAS9 (CA90's, TNG
Framework,... whatever they call it today).


Subject: CA-Spool Message ESF735

CA-Spool 11.5 is issuing message "ESF735  CA Health Checker
Initialization
failed with RC=40" and it is not documented.  Any ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA-Spool Message ESF735

[Knutson, Sam]

We have the CA Health Checker support setup and it is useful for the
products that leverage it well like CA-1.  The install was easy just
some new load modules dropped into CAILIB.

https://support.ca.com/ yields the article below.

Document ID:TEC500517 
Tech Document
Title:  What causes, at CA Spool startup, message 'ESF735 CA Health
Checker Initialization failed with RC=40 and Reason Code=' to be
written to the CA Spool JOBLOG? 


Description

At CA Spool r11.5 startup, message 'ESF735 CA Health Checker
Initialization failed with RC=40--Reason Code=000' can be written to the
CA Spool JOBLOG.

Solution

ESF735 means that the CA Health Checker is not installed in the current
system. Please review the CA Common Services solutions RI05071 and
RI05073, for information on how to download and install the CA Health
Checker common component, FMID CEF5C00.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John P Kalinich
Sent: Thursday, April 08, 2010 1:28 PM
To: IBM-MAIN@bama.ua.edu
Subject: CA-Spool Message ESF735

CA-Spool 11.5 is issuing message "ESF735  CA Health Checker
Initialization
failed with RC=40" and it is not documented.  Any ideas?

Regards,
John K

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Terri E Shaffer]

By design PTF's only get tagged an RSU level I think every 2-3 months, which is 
why we do quarterly RSU levels 3,6,9,12. We have been doing it this way for 5 
years and have not had to many headaches. Ibm did have issues when we rolled 
z/os 1.9 to early and needed RSUxx03+many hipers to be stable. The other saving 
grace is IBM stopped accepting all maintanence when a serverpac is delivered 
and you then have the ability to restore the broken ptf's.

Thanks

Ms. Terri E. Shaffer 
terri.e.shaf...@jpmchase.com
Engineer
J.P.Morgan Chase & Co.
GTI DCT ECS Core Services zSoftware Group / Emerging Technologies 
Office: # 614-213-3467
Cell: # 412-519-2592 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Mary Anne Matyaz
Sent: Thursday, April 08, 2010 1:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/OS 1.11

I don't really have a great answer for that Greg. Mainly I guess because this 
process was set up prior to RSU's. :)  But seriously, sometimes a PTF will be 
in 
PUT1001 but RSU1002. RSU's only save about 20%, IIRC, and it seems like half 
the time some schmuck will want a PTF on that wasn't in the RSU. 

But I'm open to debate...go ahead, change my mind! :) 

Mary Anne 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11 - and FIXCAT Comment

[Marna WALLE]

On Thu, 8 Apr 2010 10:04:41 -0500, Mark Zelden  wrote:

>Thanks.  Yes, that explain the coexistence part.  But shouldn't a PTF
identified
>in the PSP buckets also  be coded with ""IBM.ProductInstall-RequiredService"?
>I thought that was the FIXCAT category that was to replace the PSP
>tool.  I initially installed all that "required" service and then later on I
>actually
>read the PSP buckets (just like "the old days") and found I was missing a
>PTF that was coded with IBM.Coexistence.z/OS.V1R11.
>
>So moving forward, I will always do both to get the PSP identified maintenance,
>but I wasn't sure if this was a mistake or WAD.

Right - a PTF in the PSP bucket should have a FIXCAT for
"IBM.ProductInstall-RequiredService".  If you find a PTF in the PSP bucket
that does NOT have this as one of its FIXCATs, then please let us know. 
That category completely replaces the PSP tool (aka EPSPT) - which hopefully
no one is using at this point.

The PSP bucket may have mentioned in text to make sure that you use the
coexistence FIXCAT for a release (for instance,
"IBM.Coexistence.z/OS.V1R11"), but that doesn't mean that the
IBM.Coexistence.z/OS.V1R11 PTFs will be marked as
IBM.ProductInstall-RequiredService or vice versa.   These two FIXCATs have
different meanings, and they may or may not both be there for a particular
PTF.  Was the PTF that you found you were missing *ONLY* had the
IBM.Coexistence.z/OS.V1R11 FIXCAT on it *AND* was listed in the PSP bucket?

In general on an ongoing basis, you could do a REPORT MISSINGFIX for
IBM.Coexistence.z/OS.V1R11 against a z/OS R11 system, however, I'm not sure
it would turn up very much.  It certainly won't hurt.  Its real benefit is
identifying missing PTFs on z/OS R9 and z/OS R10 systems while they will be
coexisting with z/OS R11.  You didn't mention it but while we are on the
subject - you may want to add on an ongoing basis
IBM.TargetSystem-RequiredService.z/OS.V1R11 to that FIXCAT list you run
against your z/OS R11 system.  Those PTFs are for z/OS program products (not
the z/OS product itself!) which run on z/OS R11.  That may turn up things!

-Marna WALLE
z/OS System Build and Install

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Rexx to submit job

[Betsy Jeffery]

I'm looking for a rexx sample of submitting a batch job.  Does anyone have a 
snippet of code they can share?
TIA,
Betsy Jeffery

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[R.S.]

W dniu 2010-04-08 15:33, Paul Gilmartin pisze:
[...]

My understanding of IBM's integrity statement (not verbatim) is that
no unauthorized program can attain superviser state, key 0, or
otherwise escalate its privileges.  So, yes, if an unauthorized program
does this, it's pretty automatically cause for an integrity APAR for
an unauthorized program.


My understanding is the same, however I disagree with the secon 
sentence. IMHO if any unauthorized program is able to escalate its 
privileges then integrity APAR should be issued for *operating system*, 
not the program itself. Otherwise you don't try to fix security hole, 
you only try to stop (one of) the hole explorers. I smell Windows... ;-)


BTW: This is far off topic. I mean original thread, but it's still about 
z/OS.


Regards
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx to submit job

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Betsy Jeffery
> Sent: Thursday, April 08, 2010 1:19 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Rexx to submit job
> 
> I'm looking for a rexx sample of submitting a batch job.  
> Does anyone have a 
> snippet of code they can share?
> TIA,
> Betsy Jeffery

Well, that is sort of vague. The simpliest way that I know if would be to have 
the JCL in a stem variable. JCL.0 would contain the number of "cards". They 
would be, in order, in JCL.1, JCL.2, ... , JCL.n . Use either BPXWDYN or 
ALLOCATE to allocate an INTRDR, the EXECIO to write the "cards".

rc=BPXWDYN("ALLOC RTDDN(DDNAME) SYSOUT WRITER(INTRDR)")
IF RC<>0 THEN 
   SAY "CANNOT ALLOCATE INTERNAL READER"
   EXIT 16
END
"EXECIO * DISKW "DDNAME"(STEM JCL. FINIS"
"FREE DDN("DDNAME")"

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
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

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx to submit job

[Hayim Sokolsky]

Betsy,

The following excerpts are from a REXX exec I run under ISPF edit, but 
would work outside of ISPF as well. 

The first version used the SUBMIT command, which has the advantage of 
capturing the submitted jobname and jobnumber. It echoes back to the 
persons submitting under ISPF using message "ISRZ001" where the text is 
set in variable "zedlmsg".

submit_job: 
  temp_dsn = "'"userid()".TEMPDSN.D"date('J')".T"hhmmss".CNTL'" 
 
  call tso_cmd "FREE FILE($REXXSUB)" 
  call tso_cmd "ALLOCATE FILE($REXXSUB) DSN("temp_dsn") NEW DELETE", 
   "UNIT(SYSDA) SPACE(5 5) TRACK", 
   "RECFM(F B) LRECL(80) BLKSIZE(1600)" 
  call tso_cmd "EXECIO" job.0 "DISKW $REXXSUB (STEM JOB. FINIS" 
  call tso_cmd "SUBMIT" temp_dsn 
 
  zedsmsg = '' 
  zedlmsg = msg.1 
  address ISPEXEC "SETMSG MSG(ISRZ001)" 
 
  call tso_cmd "FREE FILE($REXXSUB) DELETE" 
  return 
 
tso_cmd: 
  procedure expose rc msg. job. cmd. 
  parse arg command 
  msg.0 = 0 
  x = outtrap('msg.','*') 
  command 
  x = outtrap('OFF') 
  return rc 

The second version does not obtain the job information. Instead it 
directly writes to the internal reader (and doesn't require ISPF or the 
SUBMIT command)...
Note that you can probably eliminate the whole tso_cmd routine if you 
don't care about return codes or trapping any results...

submit_job: 
  call tso_cmd "FREE FILE($REXXSUB)" 
  call tso_cmd "ALLOCATE FILE($REXXSUB) SYSOUT(A) WRITER(INTRDR) REUSE",
   "RECFM(F B) LRECL(80) BLKSIZE(1600)" 
  call tso_cmd "EXECIO" job.0 "DISKW $REXXSUB (STEM JOB. FINIS" 
 
  call tso_cmd "FREE FILE($REXXSUB) DELETE" 
  return 
 
tso_cmd: 
  procedure expose rc msg. job. cmd. 
  parse arg command 
  msg.0 = 0 
  x = outtrap('msg.','*') 
  command 
  x = outtrap('OFF') 
  return rc 


Hayim
_
Hayim Sokolsky, CISSP
Mainframe Security Architect
DTCC Corporate Information Security
18301 Bermuda Green Dr, MS 1-CIS
Tampa FL 33647-1760

Tel. (813) 470-2177



Betsy Jeffery  
Sent by: IBM Mainframe Discussion List 
2010.04.08 14:18
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Rexx to submit job






I'm looking for a rexx sample of submitting a batch job.  Does anyone have 
a 
snippet of code they can share?
TIA,
Betsy Jeffery

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



_

DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[R.S.]

W dniu 2010-04-08 16:32, Paul Gilmartin pisze:
[...]
> But I agree, IDCAMS is

better; it avoids a job step with 3 allocations, and it avoids
creating a data set only to delete it immediately.


No. IDCAMS is different, not better. What's better? IT DEPENDS!

For enqueued datasets IDCAMS will end with RC>0, AFAIK the same code as 
unsuccesful DELETE cause by nonexistent dataset. In simple words IDCAMS 
will not delete the datasets and let you proceed subsequent steps.


IEFBR14 (simplification) will WAIT FOR DATASETS. White message will be 
issued on operator console. For past versions of the system IEFBR14 
caused migrated dataset to be recalled and then deleted, while IDCAMS 
could delete them without recall, much quicker.


Oh, BTW IEFBR14 method does not always delete the dataset! AFAIK it is 
enough to set EXPDT for PS and MOD,DELETE will not delete it. IDCAMS 
DELETE ... PURGE will delete.



--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.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.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

WLM Macro

[ITURIEL DO NASCIMENTO NETO]

Hi all,

I'm doing some tests with IWMWSYSQ macro, using as starting point
program
QUERYSI (thanks for that) and i would like some help.

IWMWSYSQ gets WLM information regarded to importance 1-5, discretionary 
and unused service units, but there is no data related to SYSTEM or
SYSSTC. 
Is it really missing or am i doing something wrong ?

Atenciosamente / Regards / Saludos 
Ituriel do Nascimento Neto 
BANCO BRADESCO S.A. 
4254 / DPCD Engenharia de Software 
Sistemas Operacionais Mainframes 

Tel: +55 11 4197-2021 R: 22021   Fax: +55 11 4197-2814 




AVISO LEGAL 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 ADVICE 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Mark Zelden]

On Thu, 8 Apr 2010 09:41:09 -0700, Guy Gardoit  wrote:

>Haven't experienced any problems with our 3 so far.  Next maintenance cycle
>will be in July, but it will be quarterly RSU1003+HIPERs+PRP.   I've found
>using a policy of staying at currentquarterlyRSU-1 works pretty well for us
>anyway.
>

Exactly what we do (see past posts of mine).   Except when rolling out a 
new OS level -  depending on how soon after GA and how long it "sits" before
any roll outs, we may go more current.  Also, the level of user and system
testing is much greater so we feel more comfortable with being more
current than current quarter-1. 

Since my 1.11 came at RSU1001, that is what I am going with (+ PE fixes 
and some HIPERs) even though RSU1003 just came out.  In my past
posts about this I've said the reason why.   Even though RSU and CST is 
much better testing than we had in the past, a large portion of the 
community does quarterly RSU maintenance. So rolling out the current 
quarter right after it comes out has some of the same exposure
staying current with PUT did.  You are testing the maintenance for
everyone else.  But doing it this way means keeping a close tab on 
ASAP notifications to make sure we don't miss something we really
should get on right away.  Overall since we started doing this instead
of RSU*, we have had a much more stable environment.  

Realize that by the time a PTF is out, tested, hits PUT, then RSU and then 
waiting as we do, there is a long period of time that has elapsed.

As usual, YMMV.  

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx to submit job

[Scott Ford]

Like Hayim and John i submitted jobs via TSO and Netview using 
Betsy,

Like Hayim and John i submitted jobs via TSO and Netview using the SUBMIT 
command as well as the 
Intrdr example, both work well.
 
Scott J Ford
 





From: Hayim Sokolsky 
To: IBM-MAIN@bama.ua.edu
Sent: Thu, April 8, 2010 2:38:25 PM
Subject: Re: Rexx to submit job

Betsy,

The following excerpts are from a REXX exec I run under ISPF edit, but 
would work outside of ISPF as well. 

The first version used the SUBMIT command, which has the advantage of 
capturing the submitted jobname and jobnumber. It echoes back to the 
persons submitting under ISPF using message "ISRZ001" where the text is 
set in variable "zedlmsg".

submit_job: 
  temp_dsn = "'"userid()".TEMPDSN.D"date('J')".T"hhmmss".CNTL'" 

  call tso_cmd "FREE FILE($REXXSUB)" 
  call tso_cmd "ALLOCATE FILE($REXXSUB) DSN("temp_dsn") NEW DELETE", 
                  "UNIT(SYSDA) SPACE(5 5) TRACK", 
                  "RECFM(F B) LRECL(80) BLKSIZE(1600)" 
  call tso_cmd "EXECIO" job.0 "DISKW $REXXSUB (STEM JOB. FINIS" 
  call tso_cmd "SUBMIT" temp_dsn 

  zedsmsg = '' 
  zedlmsg = msg.1 
  address ISPEXEC "SETMSG MSG(ISRZ001)" 

  call tso_cmd "FREE FILE($REXXSUB) DELETE" 
  return 

tso_cmd: 
  procedure expose rc msg. job. cmd. 
  parse arg command 
  msg.0 = 0 
  x = outtrap('msg.','*') 
  command 
  x = outtrap('OFF') 
  return rc 

The second version does not obtain the job information. Instead it 
directly writes to the internal reader (and doesn't require ISPF or the 
SUBMIT command)...
Note that you can probably eliminate the whole tso_cmd routine if you 
don't care about return codes or trapping any results...

submit_job: 
  call tso_cmd "FREE FILE($REXXSUB)" 
  call tso_cmd "ALLOCATE FILE($REXXSUB) SYSOUT(A) WRITER(INTRDR) REUSE",
                  "RECFM(F B) LRECL(80) BLKSIZE(1600)" 
  call tso_cmd "EXECIO" job.0 "DISKW $REXXSUB (STEM JOB. FINIS" 

  call tso_cmd "FREE FILE($REXXSUB) DELETE" 
  return 

tso_cmd: 
  procedure expose rc msg. job. cmd. 
  parse arg command 
  msg.0 = 0 
  x = outtrap('msg.','*') 
  command 
  x = outtrap('OFF') 
  return rc 


Hayim
_
Hayim Sokolsky, CISSP
    Mainframe Security Architect
    DTCC Corporate Information Security
    18301 Bermuda Green Dr, MS 1-CIS
    Tampa FL 33647-1760

    Tel. (813) 470-2177



Betsy Jeffery  
Sent by: IBM Mainframe Discussion List 
2010.04.08 14:18
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Rexx to submit job






I'm looking for a rexx sample of submitting a batch job.  Does anyone have 
a 
snippet of code they can share?
TIA,
Betsy Jeffery

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



_

DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Paul Gilmartin]

On Thu, 8 Apr 2010 20:30:17 +0200, R.S. wrote:
>
>My understanding is the same, however I disagree with the secon
>sentence. IMHO if any unauthorized program is able to escalate its
>privileges then integrity APAR should be issued for *operating system*,
>not the program itself. Otherwise you don't try to fix security hole,
>you only try to stop (one of) the hole explorers. I smell Windows... ;-)
>
I stand corrected.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: WLM Macro

[Kelman, Tom]

I have written several WLM service policies, but I've never written code using 
the WLM macros.  So I looked in the "MVS Programming WLM Service Guide" to see 
what it was all about.  From what I gather, this particular macro is used to 
gather WLM information so that a scheduling service can make the necessary 
decisions to schedule work.  Since a user's scheduling program would probably 
not be allowed to schedule anything in to or out of the SYSTEM or SYSSTC 
service classes, I imagine that information is left out on purpose.  That's 
just my theory.  The manual doesn't mention that. 

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of ITURIEL DO NASCIMENTO NETO
> Sent: Thursday, April 08, 2010 1:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: WLM Macro
> 
> Hi all,
> 
> I'm doing some tests with IWMWSYSQ macro, using as starting point
> program
> QUERYSI (thanks for that) and i would like some help.
> 
> IWMWSYSQ gets WLM information regarded to importance 1-5, discretionary
> and unused service units, but there is no data related to SYSTEM or
> SYSSTC.
> Is it really missing or am i doing something wrong ?
> 
> Atenciosamente / Regards / Saludos
> Ituriel do Nascimento Neto
> BANCO BRADESCO S.A.
> 4254 / DPCD Engenharia de Software
> Sistemas Operacionais Mainframes
> 
> Tel: +55 11 4197-2021 R: 22021   Fax: +55 11 4197-2814
> 
> 
> 
> 
> AVISO LEGAL 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 ADVICE 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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx to submit job

[Paul Gilmartin]

On Thu, 8 Apr 2010 12:19:16 -0700, Scott Ford wrote:

>Like Hayim and John i submitted jobs via TSO and Netview using
>Betsy,

Like Hayim and John i submitted jobs via TSO and Netview using the SUBMIT 
command as well as the
Intrdr example, both work well.
 
Scott J Ford

From: Hayim Sokolsky 
To: IBM-MAIN@bama.ua.edu

submit_job:
  temp_dsn = "'"userid()".TEMPDSN.D"date('J')".T"hhmmss".CNTL'"

A lot of needless work when DYNALLOC can generate a DSNAME for you.

There's also:

5.20 "z/OS V1R10.0 Using REXX and z/OS UNIX System Services"
 ___

5.20 submit()


   ||
   | >>__submit__(__stem.__)_>< |
   ||
   ||

   Function

   Submits a job to the primary subsystem (JES), returning the job ID
   of the submitted job.

May require Unix System Services, but has no need for ISPF or TSO.

Alas, AFAIK, all methods except RYO INTRDR truncate your input to
80 columns.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: WLM Macro

[Horst Sinram]

On Thu, 8 Apr 2010 15:44:23 -0300, ITURIEL DO NASCIMENTO NETO
<4254.itur...@bradesco.com.br> wrote:

>Hi all,
>
>I'm doing some tests with IWMWSYSQ macro, using as starting point
>program
>QUERYSI (thanks for that) and i would like some help.
>
>IWMWSYSQ gets WLM information regarded to importance 1-5, discretionary 
>and unused service units, but there is no data related to SYSTEM or
>SYSSTC. 
>Is it really missing or am i doing something wrong ?

Did you specify EXTENDED_DATA=YES? Check the description of SYSI_EXT_SU_ENTRY.
Kind regards.
Horst Sinram ,IBM z/OS DFSMSrmm Architecture, z/OS Capacity Management

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11 - and FIXCAT Comment

[Mark Zelden]

On Thu, 8 Apr 2010 13:10:01 -0500, Marna WALLE  wrote:

>
> Was the PTF that you found you were missing *ONLY* had the
>IBM.Coexistence.z/OS.V1R11 FIXCAT on it *AND* was listed in the PSP bucket?
>

I thought so.  I wish I could tell you which one and I even took
a quick look at my smplog to try and help, but matching the applies to the PSP
is time consuming because they are all individual text files on my PC.  But
now that I think about it more, it's possible the PTF I am thinking of
was mentioned in a PSP bucket but not in the  "service recommendations" - 
which is what goes into  IBM.ProductInstall-RequiredService, correct?


Is there a way to get all the PSP from web IBMLINK as 1 file?  The only
seem to come as separate emails or downloaded as separate files.  :-(

  

>In general on an ongoing basis, you could do a REPORT MISSINGFIX for
>IBM.Coexistence.z/OS.V1R11 against a z/OS R11 system, however, I'm not sure
>it would turn up very much.  It certainly won't hurt.  Its real benefit is
>identifying missing PTFs on z/OS R9 and z/OS R10 systems while they will be
>coexisting with z/OS R11. 

Right, that was why I was surprised that some turned up when I ran it
against 1.11.   Now I understand why.  Thanks.  

 >You didn't mention it but while we are on the
>subject - you may want to add on an ongoing basis
>IBM.TargetSystem-RequiredService.z/OS.V1R11 to that FIXCAT list you run
>against your z/OS R11 system.  Those PTFs are for z/OS program products (not
>the z/OS product itself!) which run on z/OS R11.  That may turn up things!
>

Thanks again.  I do that also.  When I found some of those, I was trying to
find out exactly what it meant since I knew it was "new" and if there was
any complete list / descriptions of the categories like there is of
HOLDDATA reasons in the SMP/E manuals.   That prompted me to 
write Greg D. to find out the answer, which I'm sure you know is "no".  
He did tell me it has been discussed and hopefully there will be something
on the Enhanced HOLDDATA web site soon (I think that is where he said
it would be, which makes sense to me).   The best he could do was to 
direct me to use the fixcat explorer to find the new categories.

Cheers,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11

[Bell, Robert M.]

Hi List

We have had 1.11 on our sand box for just over 3 months...no issues
1.11 on our Dev box for the last 3 weeks - 2 issues
one with wd4z (java rte version issue)
and
(ptf UK49567/apar PK90754 installed in production )
PROBLEM DESCRIPTION:
Need to add run-time support to
Language Environment for COBOL programs
that are compiled with Enterprise
COBOL Version 4 Release 2.
MSGIGZ0153S Program MYPROG   was
compiled with a level of the compiler
that requires service to be installed
on Language Environment.

We plan on moving to Production on the 18th.

Regards
Robbie Bell
IBM Technical Support
Group Health Cooperative



GHC Confidentiality Statement

This message and any attached files might contain confidential information 
protected by federal and state law. The information is intended only for the 
use of the individual(s) or entities originally named as addressees. The 
improper disclosure of such information may be subject to civil or criminal 
penalties. If this message reached you in error, please contact the sender and 
destroy this message. Disclosing, copying, forwarding, or distributing the 
information by unauthorized individuals or entities is strictly prohibited by 
law.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

VSAM File Updating Issues

[John Bachiochi]

I am having some odd issues with updating a VSAM file with an Assembler 
application.  The cluster definition is as follows:

DEFINE CLUSTER ( NAME(CICS.JHB2.V604.CONFIG) -
 VOLUMES(VOL004) -  
 INDEXED SHR(3 3) TRACKS (5 1) ) -  
   DATA( NAME(CICS.JHB2.V604.CONFIG.DATA) -   
 RECORDSIZE(2040 2040) KEYS(254 0) ) -
   INDEX   ( NAME(CICS.JHB2.V604.CONFIG.INDEX) )   

The file is then seeded with 5 records, one of which contains a key of binary 
zeroes, and the other 4 records containing a key that starts with lower 
case 'h'.

When I try to add records to the file with my application, I can add them to 
my heart's content if the key value starts with something higher than 'h'.  
However, when I try to add a record with a key value lower than 'h', the add 
performs successfully, but then I cannot do a STARTBR/READNEXT on the file 
that goes past the newly added record (the CICS API returns an ENDFILE 
condition) even though I can read the record directly.  Moreover, attempts to 
read the file sequentially with a tool such as FileManager, Ditto, or even 
IDCAMS returns a 'record out of sequence' error (RC=8, error feedback of 12).

I noted that the generated CISZ for the index component was 512, and the 
data component generated a CISZ of around 18300 bytes.  I decided as a 
test to force a CISZ of 4096 for the index component (and 32700 for the data 
component, which was modified by VSAM at define time).  When I did, all of 
the updating of the file by the application worked correctly!

Has anyone had any experiences like this?  Is there something about using a 
very long key (it is only 1 byte below the maximum) that I need to be aware 
of?

Thanks in advance - John Bachiochi 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: google groups

[Shmuel Metz (Seymour J.)]

In <4bbc7573.5040...@gmail.com>, on 04/07/2010
   at 08:07 AM, Bruce Schaefer  said:

>I don't have access to IBM-main from work (we've tried many times to get 
>this resolved with no success). I've tried posting via google groups but 
>the posts don't show up (except on google groups). 

Google groups is merely an archive; bit.listserv.ibm-main is a normal news
groups. If you want your posts to show up on IBM-MAIN then you need to
send them to IBM-MAIN, *not* to bit.listserv.ibm-main. If your posts
through google groups are not showing up on bit.listserv.ibm-main then
that's something only google can help you with.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Adventure - Or Colossal Cave Adventure

[Shmuel Metz (Seymour J.)]

In
<4ff9936e7708d445a1c50e882ea37f7907673a8...@025-namsg-03.025d.mgd.msft.net>,
on 04/07/2010
   at 07:35 AM, "Petersen, Jim"  said:

>We had Milton Wylbur at an Air Force Installation I used to work at.

I might believe Milten and Wylbur.
 
-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Tom Marchant]

On Thu, 8 Apr 2010 09:07:12 -0500, Michel Castelein wrote:
>
>Using IDCAMS is more performant:

Is it?  Maybe, but it is not obvious to me.  In the case where the 
data set does exist, I'm sure that the BR14 uses fewer resources. 
The IDCAMS step has to have SYSIN and SYSPRINT allocated. 
It has to open them both, read the SYSIN and write the SYSPRINT.

>//PASOBOR EXEC PGM=IDCAMS
>//SYSPRINT DD  SYSOUT=*
>//SYSINDD  *
>  LISTCAT ENTRY(USTS.U0Z72B6..)
>  IF LASTCC=0 THEN DELETE USTS.U0Z72B6..
>  SET MAXCC=0

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Shmuel Metz (Seymour J.)]

In
,
on 04/06/2010
   at 10:21 PM, Don Williams  said:

>The possibility of disclosure may make some people reluctant.


I'd see that as a serious minus.

>It is unlikely that an integrity hole is so obscure, that only one
>person will discover it.

I'd like for the first person to discover it to report it.

>If good guys find it first, then the hole has a chance to be closed
>before the bad guys can capitalize on it.

Not if the good guys are unwilling to report it.

>unless there is a new law that requires that all integrity fixes be
>applied,

Or unless the old legal doctrine of due diligence effectively compels it.

-- 
 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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: z/OS 1.11 - and FIXCAT Comment

[Marna WALLE]

On Thu, 8 Apr 2010 15:05:45 -0500, Mark Zelden  wrote:

>I thought so.  I wish I could tell you which one and I even took
>a quick look at my smplog to try and help, but matching the applies to the PSP
>is time consuming because they are all individual text files on my PC.  But
>now that I think about it more, it's possible the PTF I am thinking of
>was mentioned in a PSP bucket but not in the  "service recommendations" -
>which is what goes into  IBM.ProductInstall-RequiredService, correct?

Right again, section 4 ("Service Recommendations") of PSP buckets is what
goes into "IBM.ProductInstall-RequiredService".

-Marna WALLE
z/OS System Build and Install

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

IDG073I Message

[Chris Burgess]

My LPARs keep steaming the following messages:

IGD073I ANOMALY DETECTED IN COMMDS PCTSYS.SMS.TEST.COMMDS - REASON CODE 
10152   
IGD042I COMMDS PCTSYS.SMS.TEST.COMMDS SUCCESSFULLY REPAIRED 
IEF196I IGD104I PCTSYS.SMS.TEST.COMMDS   RETAINED,  

When I IPL them, they get hung up on SMS. I switched over to a backup COMMDS
and the messages continue. Also, I deleted it and redefined it and it didn't
help. I appreciate any insight.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VSAM File Updating Issues

[Hal Merritt]

Is everything being done from the same address space?

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
John Bachiochi
Sent: Thursday, April 08, 2010 3:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: VSAM File Updating Issues

I am having some odd issues with updating a VSAM file with an Assembler 
application.  The cluster definition is as follows:

DEFINE CLUSTER ( NAME(CICS.JHB2.V604.CONFIG) -
 VOLUMES(VOL004) -  
 INDEXED SHR(3 3) TRACKS (5 1) ) -  
   DATA( NAME(CICS.JHB2.V604.CONFIG.DATA) -   
 RECORDSIZE(2040 2040) KEYS(254 0) ) -
   INDEX   ( NAME(CICS.JHB2.V604.CONFIG.INDEX) )   

The file is then seeded with 5 records, one of which contains a key of binary 
zeroes, and the other 4 records containing a key that starts with lower 
case 'h'.

When I try to add records to the file with my application, I can add them to 
my heart's content if the key value starts with something higher than 'h'.  
However, when I try to add a record with a key value lower than 'h', the add 
performs successfully, but then I cannot do a STARTBR/READNEXT on the file 
that goes past the newly added record (the CICS API returns an ENDFILE 
condition) even though I can read the record directly.  Moreover, attempts to 
read the file sequentially with a tool such as FileManager, Ditto, or even 
IDCAMS returns a 'record out of sequence' error (RC=8, error feedback of 12).

I noted that the generated CISZ for the index component was 512, and the 
data component generated a CISZ of around 18300 bytes.  I decided as a 
test to force a CISZ of 4096 for the index component (and 32700 for the data 
component, which was modified by VSAM at define time).  When I did, all of 
the updating of the file by the application worked correctly!

Has anyone had any experiences like this?  Is there something about using a 
very long key (it is only 1 byte below the maximum) that I need to be aware 
of?

Thanks in advance - John Bachiochi 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use

[Don Williams]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Thursday, April 08, 2010 4:32 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition
> required for any SMP/E use
> 
> In
>  mpaur2woba...@gmail.com>,
> on 04/06/2010
>at 10:21 PM, Don Williams  said:
> 
> >The possibility of disclosure may make some people reluctant.
> 
> 
> I'd see that as a serious minus.

I agree, they should report problem; but the consensus seems to be that some
people may not report them.

> 
> >It is unlikely that an integrity hole is so obscure, that only one
> >person will discover it.
> 
> I'd like for the first person to discover it to report it.

So would I. 

> 
> >If good guys find it first, then the hole has a chance to be closed
> >before the bad guys can capitalize on it.
> 
> Not if the good guys are unwilling to report it.

Hmm. If they are unwilling to report it, should we consider them one of the
good guys?

> 
> >unless there is a new law that requires that all integrity fixes be
> >applied,
> 
> Or unless the old legal doctrine of due diligence effectively compels
> it.
> 

Yes, if due diligence happened more often, the world would be a better
place.

> --
>  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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: VSAM File Updating Issues

[John Bachiochi (DSI)]

Yes.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Hal Merritt
Sent: Thursday, April 08, 2010 1:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: VSAM File Updating Issues

Is everything being done from the same address space?

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John Bachiochi
Sent: Thursday, April 08, 2010 3:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: VSAM File Updating Issues

I am having some odd issues with updating a VSAM file with an Assembler 
application.  The cluster definition is as follows:

DEFINE CLUSTER ( NAME(CICS.JHB2.V604.CONFIG) -
 VOLUMES(VOL004) -  
 INDEXED SHR(3 3) TRACKS (5 1) ) -  
   DATA( NAME(CICS.JHB2.V604.CONFIG.DATA) -   
 RECORDSIZE(2040 2040) KEYS(254 0) ) -
   INDEX   ( NAME(CICS.JHB2.V604.CONFIG.INDEX) )   

The file is then seeded with 5 records, one of which contains a key of
binary 
zeroes, and the other 4 records containing a key that starts with lower 
case 'h'.

When I try to add records to the file with my application, I can add them to

my heart's content if the key value starts with something higher than 'h'.  
However, when I try to add a record with a key value lower than 'h', the add

performs successfully, but then I cannot do a STARTBR/READNEXT on the file 
that goes past the newly added record (the CICS API returns an ENDFILE 
condition) even though I can read the record directly.  Moreover, attempts
to 
read the file sequentially with a tool such as FileManager, Ditto, or even 
IDCAMS returns a 'record out of sequence' error (RC=8, error feedback of
12).

I noted that the generated CISZ for the index component was 512, and the 
data component generated a CISZ of around 18300 bytes.  I decided as a 
test to force a CISZ of 4096 for the index component (and 32700 for the data

component, which was modified by VSAM at define time).  When I did, all of 
the updating of the file by the application worked correctly!

Has anyone had any experiences like this?  Is there something about using a 
very long key (it is only 1 byte below the maximum) that I need to be aware 
of?

Thanks in advance - John Bachiochi 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IDG073I Message

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Burgess
> Sent: Thursday, April 08, 2010 3:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: IDG073I Message
> 
> My LPARs keep steaming the following messages:
> 
> IGD073I ANOMALY DETECTED IN COMMDS PCTSYS.SMS.TEST.COMMDS - 
> REASON CODE 
> 10152 
>   
> IGD042I COMMDS PCTSYS.SMS.TEST.COMMDS SUCCESSFULLY REPAIRED   
>   
> IEF196I IGD104I PCTSYS.SMS.TEST.COMMDS   
> RETAINED,  
> 
> When I IPL them, they get hung up on SMS. I switched over to 
> a backup COMMDS
> and the messages continue. Also, I deleted it and redefined 
> it and it didn't
> help. I appreciate any insight.

First SWAG is that the DASD they are on is not defined as SHARED and so is not 
being RESERVEd and RELEASEd properly during updating. Or that something else 
like GRS or MIM is converting the RESERVEs into global ENQs improperly.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
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

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Rexx to submit job

[Ted MacNEIL]

/* REXX */
address "TSO"
"SUBMIT" job
--Original Message--
From: Betsy Jeffery
Sender: IBM Mainframe Discussion List
To: IBM Mainframe Discussion List
ReplyTo: IBM Mainframe Discussion List
Sent: Apr 8, 2010 14:18
Subject: Rexx to submit job

I'm looking for a rexx sample of submitting a batch job.  Does anyone have a 
snippet of code they can share?
TIA,
Betsy Jeffery

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IMS log record sequence number first byte 'F1'x - why?

[Dell'Anno, Aurora]

Barry,

re-posting this back to the IBM-MAIN list in case anyone else may be
interested...

I have hunted around, looked up some notes AND asked some of the IMS Dev
people, we "seem" to remember that it came bout with data sharing in IMS
5, since before that it was only the LSN and the STCK was added later,
or possibly the other way round...



Thanks.
 

Aurora


 

Aurora Emanuela Dell'Anno
CA MSC
Sr. Engineering Services Architect
Tel:  +44 (0)1753 577 733
Mobile:  +44 (0)7768 235 339
aurora.della...@ca.com

http://www.ca.com/
 

P please don't print this e-mail unless you really need to!

 

 



-Original Message-
From: Barry Merrill [mailto:ba...@mxg.com] 
Sent: 04 April 2010 14:14
To: Dell'Anno, Aurora
Subject: RE: IMS log record sequence number first byte 'F1'x - why?

Many thanks for taking the time to educate me.

It is the final 8-byte LSN that has the 'F1'x in the first byte in this
particular IMS log file.

Has this always been the design, or is this something new?

I've always INPUT the IMSRECNO with SAS as a PIB8. numeric, but I had
not previously implemented duplicate data removal from the IMS log
record post-processing, so I had never had the occasion to look closely
at the actual LSN value.  But when I decided this week to add that logic
(by reading the same file twice, PROC SORT NODUP'ing, and confirming
that exactly one half of each record type was removed) I hit really
strange problems that took a LONG time for me to realize they were the
result of that first byte being non-zero, plus a SAS design "error" that
I had documented ten years ago and had forgotten.

When a 8-byte field is input in SAS as a numeric, I had completely
forgotten that only 7-bytes of "mantissa" are storable in their internal
floating point values, and that caused LOTS of identical LSN values,
with 10*19 magnitude, due to the low order digits being truncated, and
those duplicate LSN values were the cause of my NODUP failure.

Now, realizing the my/SAS glitch, I INPUT it as a $CHAR8 and all 8-bytes
are preserved and my NODUP works just fine now, but I still wanted to
document what's in that first byte.

And to show my complete lack of knowledge of how the IMS log files I get
from customers are created, can you elaborate on the "position of the
file in the merge sequence"?
I just though you "dumped" the IMS log,
and was unaware of a merge operation in that process.

Very MERRILLY yours,

Barry Merrill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Ted MacNEIL]

>In simple words IDCAMS 
will not delete the datasets and let you proceed subsequent steps.

Yes it will.

You cab query and set condition codes.

 DELETE dsn
 IF MAXCC<9 THEN SET MAXCC=0

I've been doing this since 1981!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Scott Rowe]

No, Ted, I won't:
 
 DELETE 'SROWE1.TEST' 
IKJ56225I DATA SET SROWE1.TEST ALREADY IN USE, TRY LATER  
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IDC0551I ** ENTRY SROWE1.TEST NOT DELETED 
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 
  
 IF MAXCC<9 THEN SET MAXCC=0  
  
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 

>>> Ted MacNEIL  4/8/2010 5:23 PM >>>
>In simple words IDCAMS 
will not delete the datasets and let you proceed subsequent steps.

Yes it will.

You cab query and set condition codes.

DELETE dsn
IF MAXCC<9 THEN SET MAXCC=0

I've been doing this since 1981!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Scott Rowe]

Oops, c /I/it/

>>> Scott Rowe  4/8/2010 5:48 PM >>>
No, Ted, I won't:

DELETE 'SROWE1.TEST' 
IKJ56225I DATA SET SROWE1.TEST ALREADY IN USE, TRY LATER  
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IDC0551I ** ENTRY SROWE1.TEST NOT DELETED 
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 
  
IF MAXCC<9 THEN SET MAXCC=0  
  
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 

>>> Ted MacNEIL  4/8/2010 5:23 PM >>>
>In simple words IDCAMS 
will not delete the datasets and let you proceed subsequent steps.

Yes it will.

You cab query and set condition codes.

DELETE dsn
IF MAXCC<9 THEN SET MAXCC=0

I've been doing this since 1981!

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Paul Gilmartin]

On Thu, 8 Apr 2010 17:50:44 -0400, Scott Rowe wrote:

>Oops, c /I/it/
>
 Scott Rowe 4/8/2010 5:48 PM >>>
>No, Ted, I won't:
>
>DELETE 'SROWE1.TEST' 
>IKJ56225I DATA SET SROWE1.TEST ALREADY IN USE, TRY LATER  
>IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
>IDC0551I ** ENTRY SROWE1.TEST NOT DELETED 
>IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 
>  
>IF MAXCC<9 THEN SET MAXCC=0  
>  
>IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 
>
 Ted MacNEIL  4/8/2010 5:23 PM >>>
>>In simple words IDCAMS 
>will not delete the datasets and let you proceed subsequent steps.
>
Ah, yes.  But Ted cleverly deleted the two lines in which
R.S. clearly stated the condition under which the IDCAMS
approach fails.  So Scott's example doesn't count.

End the job with:

//ENQ  EXEC  PGM=IEFBR14,COND=(0,LE)
//EXCL  DD   DISP=MOD,DSN=SROWE1.TEST,...

... and all will be well.  It's likely (WAG) that the OP's
JCL already contains a step that accomplishes this.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JCL QUESTION

[Ted MacNEIL]

>No, Ted, I won't:

Won't what?

You cannot control ENQ's.
All we can do is all we can do!

Nothing is perfect.
DISP=(MOD,etc) won't work with and ENQ'd DSN either.

If you haven't locked it, you don't have it!
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Your friend wants you to know about World Community Grid!

[Chris Blaicher]

"World Community Grid has enabled my lab at Scripps to engage in critical 
computational research to design new anti-HIV drugs based on molecular 
structure. World Community Grid has allowed us to complete very complex 
research studies in six months that would have taken five years."

- Professor Arthur Olson Department of Molecular Biology, The Scripps Research 
Institute, HIV Researcher. 

Your friend Chris Blaicher would like you to read this important message:

I know how important science is to you and we both know that it can have a 
postive impact on the lives of others.  You may contribute to technology that 
is changing lives too, it's free and easy. Our planet's getting smaller, 
flatter and smarter every day, and it's no wonder with initiatives like World 
Community Grid. Please join me in supporting this groundbreaking program, which 
has helped to dramatically reduce research time in various non-profit 
humanitarian projects since its inception in 2004. 

One example is the Human Proteome Folding Project at The Institute for Systems 
Biology (ISB). It used World Community Grid to predict 50,000 previously 
unknown protein structures. This information will help combat Parkinson's 
disease, cancer, cystic fibrosis and other diseases. The project was completed 
in just months. Had ISB used its own computing resources, it would have taken 
approximately 100,000 years.

Ongoing research projects include: 

Discovering Dengue Drugs - Together - Phase 2
Help Cure Muscular Dystrophy - Phase 2
Help Fight Childhood Cancer
Nutritious Rice for the World
Help Conquer Cancer
Human Proteome Folding - Phase 2
fighta...@home


How World Community Grid works:
It's easy. Just register and download a simple and secure program. The program 
can detect whenever your computer has unused computer cycles and during these 
times, your computer requests work from World Community Grid's server, performs 
computations on this data and sends the results back. It requires no effort on 
your part at all and it's completely safe!  Also, the progams settings may 
easily be changed to suit your needs. I believe World Community Grid can 
greatly advance the work of the scientific community.  Please go to the website 
at www.worldcommunitygrid.org and register today.

* You can easily change the settings of the program to suit your needs.

Thank you and see you on World Community Grid!,

Chris Blaicher

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Console's behaviour when no paths available

[W. Kevin Kelley]

On Thu, 8 Apr 2010 12:26:34 -0400, Tony Harminc  
wrote:

>On 8 April 2010 08:19, Barbara Nitz  wrote:
>
>> Well, I was told that IBM assumes it was 'a network problem' (and not
>> something in the OSA card itself) that caused the channel control check to 
be
>> presented. IBM then took the cop-out and said that to be 100% sure they 
will
>> need to have a trace active in the OSA card that needs to get stopped 
within
>> 5 minutes after the problem occuring.
>>
>> Never mind that IBM does not tell us *how* to detemine that it was this
>> problem and how to stop the trace in the time window, especially at
>> o:dark:30. So much for finding the *cause* of the problem.
>
>Wouldn't it be by definition a hardware problem in the OSA card if a
>"network problem" is capable of causing a channel control check? My
>reading of the definition of Channel Control Check in the Principles
>of Operation is that it is a machine malfunction that cannot be caused
>by external data or conditions. Perhaps you should ask them if the OSA
>card has been granted a deviation from the POO; they take this stuff
>fairly seriously.
>

Barbara,

Sorry, I wasn't on IBMMAIN last night. We've had a lively debate about what 
happened and what we might be able to do to handle it more intelligently. 

W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

OT IBM breaks OSS patent promise, targets mainframe emulator

[Ed Gould]

http://arstechnica.com/open-source/news/2010/04/ibm-breaks-oss-patent-promise-targets-mainframe-emulator.ars



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
  

(slightly OT) CA is laying off 1,000 workers and expects to take a $50m hit in pre-tax charges relating to the jobs cull

[Ed Gould]

http://www.channelregister.co.uk/2010/04/06/ca_job_cuts/



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
  

Re: (slightly OT) CA is laying off 1,000 workers and expects to take a $50m hit in pre-tax charges relating to the jobs cull

[zMan]

On Thu, Apr 8, 2010 at 10:04 PM, Ed Gould  wrote:

> http://www.channelregister.co.uk/2010/04/06/ca_job_cuts/
>

No disrespect to the many actual CA workers, but having served my own
sentence there, I'm quite confident that they could lay off 1,000 bodies
without selecting any *workers*.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CA-Spool Message ESF735

[Barbara Nitz]

>CA-Spool 11.5 is issuing message "ESF735  CA Health Checker Initialization
>failed with RC=40" and it is not documented.  Any ideas?

It appears that CA was (also) tasked with coming up with health checks. The 
result was that they are not documented properly. When we ran into this, we 
had them dig for the documentation, and they will provide it in a future 
release 
in the standard books.

In our case, we got exceptions that no one had an inkling how to handle. We 
just deleted the checks in the parmlib member, as our product guy said they're 
useless checks, anyway.

Regards, Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html