Re: Opinions/experience on sharing catalogs outside plex

[Anthony Thompson]

Sounds like a bad idea to me. You can't guarantee the integrity of the user 
catalogues.

Can you set up the external systems as NJE nodes and get them to submit jobs to 
your sysplex instead?

Ant.  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Schramm
Sent: Thursday, 9 April 2020 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Opinions/experience on sharing catalogs outside plex

I am considering sharing some usercats outside of a sysplex.  What I can find 
is that sysiggv2 must be kept as a reserve to do so.

Looking for others that have had to do this.

One question I had was, what happens on a ispf 3.4 when the data set is part of 
the catalog but exists in another system?  Ief238d?

Thanks,

Rob Schramm

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

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

Re: JES2 - stopping users from sending output to specific outputclass

[Anthony Thompson]

Jantje pointed out what seems the sensible solution, use the ACF2 JESSPOOL 
resource class: 

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/security/ca-acf2-for-z-os/16-0/administrating/jes-security.html

Using JES(2?) exits might be too much: not many shops like exits these days 
since then they need to employ clever sysprogs that know assembler to maintain. 
I'll point out that as of z/OS 2.4, IBM have begun introducing JES2 Policies 
intended to replace JES2 exits.

Another more trivial solution might be to restrict to a certain privileged set 
of users the ability to view that SYSOUT class via SDSF using 
ISFPARMS/PARMLIB(ISFPRMxx). Others would probably stop using that class if it 
doesn't do them any good. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Costley
Sent: Tuesday, 3 March 2020 7:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 - stopping users from sending output to specific outputclass

We are having an issue with users using a restricted output class based on 
standards. We are looking for a way to prevent this from happening by canceling 
the job if the JCL contains SYSOUT=X.   We are an ACF2 shop but I am unaware if 
ACF2 security can limit this through a security definition. The other option is 
a possible exit.  

Has anyone done this in the past and has a suggestion on the best approach? 

Thanks,
Keith Costley

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

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

Re: HSFLOG and HSFTRACE

[Anthony Thompson]

> On our z/OS 2.4 system there's still a SDSFAUX address space.

Yes, SDSFAUX remains to execute various data gatherers, XCF communications and 
so on, but the allocation of HSFLOG and HSFTRACE was moved to the SDSF address 
space with z/OS 2.3.

Ant.

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

Re: HSFLOG and HSFTRACE

[Anthony Thompson]

> I believe it's SDSFAUX that allocates these files...
> Dan

Used to be SDSFAUX. With z/OS 2.3, the SDSF address space took over this 
function.

Ant.

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

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

Re: HSFLOG and HSFTRACE

[Anthony Thompson]

> Hi,
> SDSF allocates two SYSOUT files named HSFLOG and HSFTRACE.
> How do I change the SYSOUT Class these files use?

> I am running z/OS v2.3

> Gadi

SYSOUT class for SDSF trace can be set in ISFPRMxx

OPTION TRCLASS(output class)

Defaults to class A.

I don't see an ISFPRMxx parameter for log class, but both trace and log sysout 
class can be set on the SDSF start command, or a modify command:

S (or F) SDSF,LOGCLASS=class,TRCLASS=class

It's all documented in the obvious manual, SDSF Operation and Customization.

Ant.

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

Re: Findproc CBTTAPE ?

[Anthony Thompson]

Lizette, there's another caveat there too. A procedure is identified by its 
member name, but the contents of that library member may not necessarily 
contain the member name. 

An unrealistic example:

.PROCLIB(PLURGH) contains:

IEFBR14 PROC
IEFBR14 EXEC PGM=IEFBR14
IEFBR14 PEND

Batch 3.14 search for PLURGH won't find that.

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Tuesday, 9 July 2019 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Findproc CBTTAPE ?

That works so long as the proc you are looking for is in the JES2 environment.  
If your users are using JCLLIB statements, then you need to find all of the 
JCLLIB Datasets and scan for those.

You can do the same thing.

JCLLIB statements with all of your proclibs.  Then try the JCL process.

Caveat.  If the proc member is in multiple libraries, you will only find the 
first occurrence.

I will use the 3.14 option in batch and concatenate all of my proclibs and then 
SEARCH for what I am looking for.  Tends to find those in all libraries rather 
than just the first one.


If you have a strong naming convention, like SYS1.**.PROCLIB bring those up in 
3.4 and then SRCHFOR or MEMBER on the command line.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Anthony Thompson
> Sent: Monday, July 08, 2019 8:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Findproc CBTTAPE ?
> 
> I just run JCL invoking the proc with a deliberate JCL error.
> 
> Like so:
> 
> //
> /*ROUTE XEQ <--- to pick up any certain system's standard proclib
> order of search
> //FINDPROC EXEC ,JCLERROR=YES
> 
> The IEFC001I message in the JESYSMSG dataset tells where the procedure 
> was found.
> 
> IEFC001I PROCEDURE 
> 
> You don't need some clever utility from CBT or any other source to 
> figure this out.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jake Anderson
> Sent: Tuesday, 9 July 2019 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Findproc CBTTAPE ?
> 
> Hi
> 
> Is there a file within CBTTAPE to find a specific proc among the JES2 procs ?
> 
> I am looking through but still didn't get a one yet .
> 
> Any pointers would be appreciated
> 
> Jake.
> 

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

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

Re: Findproc CBTTAPE ?

[Anthony Thompson]

I just run JCL invoking the proc with a deliberate JCL error.

Like so: 

//
/*ROUTE XEQ <--- to pick up any certain system's standard proclib 
order of search
//FINDPROC EXEC ,JCLERROR=YES

The IEFC001I message in the JESYSMSG dataset tells where the procedure was 
found.

IEFC001I PROCEDURE 

You don't need some clever utility from CBT or any other source to figure this 
out.

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Tuesday, 9 July 2019 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Findproc CBTTAPE ?

Hi

Is there a file within CBTTAPE to find a specific proc among the JES2 procs ?

I am looking through but still didn't get a one yet .

Any pointers would be appreciated

Jake.

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

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

Re: Who is changing a user's ISPF profile

[Anthony Thompson]

You probably want SMF record type 15, to tell you who has opened a dataset for 
output, and when.

Are you a RACF shop? You can define a RACF profile for the user's ISPF profile 
dataset to ensure that only they have more than READ access, and use 
NOTIFY(userid) to get a TSO message whenever some other user/whatever fails the 
RACF check. ACF2 has similar facilities, and I've never met TSS.

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Friday, 5 July 2019 12:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Who is changing a user's ISPF profile

Hi,

A user is complaining that 'someone' is changing their ISPF profile and setting 
that they set up are changing.

Can I track this in SMF and see who, if anyone is doing this?

I saw the SMF 42 records are created when members in a PDS or PDS/E are changed.

Will they pick up ISPF profile changes?



We are running z/OS v2.2.



Thanks



Gadi



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

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

Re: BATCH JOB TO RUN GRS COMMAND

[Anthony Thompson]

Provided you have the appropriate authorities...

Batch job: 

//jobcard
//SDSFCMD  EXEC PGM=IKJEFT01
//SYSTSPRT DD   SYSOUT=*
//SYSPROC  DD   DISP=SHR,DSN=Your.REXX.library
//SYSTSIN  DD   *
  %SDSFCMD D GRS,RES=(*,SYS1.LINKLIB)
/*

SDSFCMD REXX: 

/*REXX*/
blah = ISFCALLS('ON')
ISFCONS  = "ANTCONXX"
ISFDELAY = "1"
PARSE ARG input
cmd.0=1
cmd.1=input
ADDRESS SDSF ISFSLASH "(cmd.)"
IF (ISFULOG.0 > 0) THEN
DO i=1 TO ISFULOG.0
  SAY ISFULOG.i
END
EXIT 0

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
willie bunter
Sent: Saturday, 1 June 2019 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BATCH JOB TO RUN GRS COMMAND

Hallo All,
Would anybody have an example to run the GRS command for the following dsn  via 
a batch job :
 DGRS,RES=(*,SYS1.LINKLIB)
Thanks in advance

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

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

Re: master JCL

[Anthony Thompson]

Operator command D IPLINFO,MSTRJCL

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, 31 May 2019 12:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: master JCL

On Wed, 29 May 2019 22:10:23 +, Pommier, Rex  wrote:

>Hello listers,
>
>I'm apparently having a case of brain-rrain.  Is there an easy way to display 
>the currently used master JCL?  I know I can look at LINKLIB and PARMLIB and 
>see what's there, but is there a way of displaying what's actually running?  I 
>thought at one point in time I could see it in Omegamon or someplace.  In this 
>case, google was not my friend.  :-(  Any assistance would be greatly 
>appreciated.

SHOWMVS maybe? On the CBT tape.

--
Tom Marchant

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

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

Re: CBRSPLCS question

[Anthony Thompson]

I haven't used that utility, but reading the source in SYS1.SAMPLIB(CBRSPLCS) 
tells me there should be a space between the SV and the volser. So I think it's 
complaining about not finding volume '2 '.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gadi Ben-Avi
Sent: Monday, 1 April 2019 3:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CBRSPLCS question

Hi,
I am trying to use CBRSPLCS to change a group of volumes to scratch.
I am using the following JCL:
//CBRSPLCS EXEC PGM=CBRSPLCS,REGION=0M
//OUTDDDD SYSOUT=*
//INDD DD *
SVN2  MLVTL

I get:
SVN2  MLVTLQVR   RETURN CODE = 0004, REASON CODE = 0063.

Which, from what I found means that the volume N2 is not in the library.

Am I doing something wrong?

Gadi

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

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

Re: IARST64 in addrr

[Anthony Thompson]

I believe the OP is referring to the system trace table entries for a page 
fault.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, 13 March 2019 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IARST64 in addrr

Joseph Reichman wrote:

>I have been getting S0C4 pic 11 11 meaning not a translation error or a 
>invalid address but that it wasn’t allocated

What is 'pic 11 11'? Just like the other wizards, I am also confused by what 
you wrote.

Please post the full Abend message(s) and all the return and reason codes as 
well the register contents.

Groete / Greetings
Elardus Engelbrecht

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

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

Re: How to tell what allocated a dataset never opened

[Anthony Thompson]

What about the GRS Enqueue Monitor? See the Planning: GRS manual.

The enqueue monitor tells you what module issues the enqueue, although if it's 
a CLIST doing the allocation it will probably just say it's some IKJ* thingy. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Beck
Sent: Friday, 9 November 2018 3:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to tell what allocated a dataset never opened

Thank you all for the input.  The datasets already exist and testing with an 
allocate then free in TSO does not show any updating in the SMF60 record for 
the VVDS NVR records. :(  I like the see-who-complains approach, but 
unfortunately most of the victims will be end users, and the developers of the 
CLISTs/Rexx/dialog are usually long gone, so the brown water will come back to 
us!

The IGD104I messages list both the dataset name and DDNAME for the TSO users, 
so if there are no other suggestions, I'll let the owner of the retired system 
pour over the OPERLOGs then scan for the DDNAMEs.

Jim

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

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

Re: get ECSA key 7 storage under CICS

[Anthony Thompson]

The SDSF SVC ran under SVC 109, one of those ESR (extended SVC routing) 
routines.

I once wrote a bunch of programs/menus that did RACF processing under CICS, 
essentially duplicating the RACF ISPF panels, but instead of using a magic SVC 
to authorise CICS application code, I established an authorised CICS sub-task 
at CICS initialization (when CICS code was still authorised). All the 
authorised processing happened on the sub-task side, under the usual RACF 
rules.  

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, 19 October 2018 1:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: get ECSA key 7 storage under CICS

The SDSF SVC had some 'integrity checks' that would complicate any spoofing 
effort, but it was always a bad idea. Good riddance. Woe be to any similar 
attempt at the quick-and-dirty solution to an APF problem. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, October 18, 2018 8:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: get ECSA key 7 storage under CICS

On Thu, 18 Oct 2018 14:08:33 +, Barkow, Eileen  
wrote:

>In order to call the SVC a programmer would have to know about it first 
>as well as have a need for it; neither of which applied to any CICS 
>application programmers.
>

Someone breaking into your systems would always have a need for something handy 
like that... ;)

Didn't SDSF include something similar a long time ago?  back when you used to 
get source for SDSF.  Although IIRC it had a rudimentry check for the 
eyecatcher of the caller to make sure the caller was 'authorized'  to use it.

Dana


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

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

Re: ISPF issue - new system

[Anthony Thompson]

As Paul said, you will need volumes mounted as PUBLIC in your VALTLST to be 
able to satisfy non-specific volume allocation requests in a non-SMS 
environment (which is likely what your ISPF initial EXEC is doing to 
pre-allocate new ISPF datasets).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Feller, Paul
Sent: Saturday, 6 October 2018 6:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF issue - new system

Without SMS you will need to have DASD volumes mounted as 
PRIVATE/PUBLIC/STORAGE.  I believe without the PUBLIC or STORAGE volumes you 
will have a hard time allocating new dataset or temp datasets.  I would think 
any datasets that are cataloged should get found through the proper catalog 
search.

Thanks..

Paul Feller
AGT Mainframe Technical Support
paul.fel...@transamerica.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vinoth M
Sent: Friday, October 05, 2018 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF issue - new system

Hi All,

We have build a new system and we are bringing this system without SMS 
configuration.
We got the VTAM, TSO, TCPIP up and we are ready to login TSO, when we login to 
TSO, the ISPF profiles are not getting allocated, since it’s pointing to SMS 
dataset but we have disabled SMS.

May I know, where to change the SMS stuffs to NON-SMS volume, do I no to change 
in parmlibs or any other procs, please let me know.

Thanks

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

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

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

Re: SMP/E Fixcat Categories in batch?

[Anthony Thompson]

Probably not what you want, but LIST HOLDDATA HOLDFIXCAT?

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Lowe
Sent: Wednesday, 19 September 2018 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E Fixcat Categories in batch?

Hi,
   Is there anyway of listing out all of the SMP/E FIXCATs via batch.?

Thanks, Roger

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

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

Re: OMVS file type Char

[Anthony Thompson]

From the USS User Guide, Ch. 14 (SA23-2279-30).

A character special file defines one of the following:
– A terminal (/dev/ptyp and /dev/ttyp).
– The default controlling terminal for a process (/dev/tty).
– A null file (/dev/null). Data written to this file is discarded; hence, it is 
known as the bit bucket. This file is always empty for reading.
– A zero file (/dev/zero). Data written to this file is discarded and binary 
zeros are supplied for any amount read from it.
– The random number files (/dev/random and /dev/urandom). These files provide 
random numbers for cryptographic purposes.
– A file descriptor file (/dev/fdn or /dev/fd/n).
– A system console file (/dev/console). Data that is written to this file is 
sent to the console using a write-to-operator (WTO) that displays the data on 
the system console.
– A UNIX domain socket name file. This is a path name that specifies the socket 
address for a UNIX domain socket. The path name is assigned by the application 
programmer; there is no convention for the name. The operating system creates 
the file. 
– A Communications Server remote tty file (for example, rty) that 
corresponds to the requesting terminal on the originating Communications Server 
node. The name is assigned by the Communications Server
administrator.
– The Communications Server character special file (/dev/ocsadmin) that 
supports ioctl functions for Communications Server administrative functions.
Character special files are dynamically created by the operating system when 
they are first referenced. However, they can also be explicitly created by a 
superuser (for instance, in order to assign different permissions).

Ant.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Wednesday, 19 September 2018 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OMVS file type Char

Hi

I have got a dummy query

I was going through /var/dpi_socket and see it's a Character special type of 
file


I am going through the USS guide but I found any hit about this type of file. 
Also I can't select or copy this files .

Can someone please explain what are Character special type file ?

Jake

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

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

Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

[Anthony Thompson]

There's no SMF record that will tell you that. Not at the member level.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, 21 May 2018 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

I think the intent is identifying what used a member in a PDS.  

For example, knowing which jobs expand which PROCLIB members


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 
> Behalf Of Anthony Thompson
> Sent: Sunday, May 20, 2018 7:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> If all you are looking for is who has opened a dataset, SMF type 14 is 
> all you should need.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Sankaranarayanan, Vignesh
> Sent: Monday, 21 May 2018 11:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> Thanks Ant, wouldnt setting SMF42 off mean I can't use DATASET EQ 
>  stuff?
> 
> – Vignesh
> Mainframe Infrastructure
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Anthony Thompson
> Sent: Monday 21-May-2018 06:57
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> Sorry for not responding earlier, I had Friday off.
> 
> SMF record 42 is for DFSMS statistics, so I avoided the SMF42* 
> undefined symbols and the invalid R4 by setting _DFSMS to 0.
> 
> SMF record 82 is for ICSF, so I got rid of the SMF82ITE undefined 
> symbol by _ICSF to 0.
> 
> And you still have to set _DFSMS07 to N for a clean assembly.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Sankaranarayanan, Vignesh
> Sent: Friday, 18 May 2018 9:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> .. I have a compiled DAF from earlier which works for DATASET EQ 
> stuff, but it doesn't recognize the RACF keywords, though I probably 
> would have let the RACF flag default to a yes when I asm it years ago.
> 
> – Vignesh
> Mainframe Infrastructure
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Sankaranarayanan, Vignesh
> Sent: 18 May 2018 13:08
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> Hi Anthony,
> 
> Looks like I'm getting DAF assemble errors to now..
> 
> ** ASMA044E Undefined symbol - SMF42S7
> ** ASMA044E Undefined symbol - SMF42FFS
> ** ASMA044E Undefined symbol - SMF42FTY
> ** ASMA044E Undefined symbol - SMF42FTM
> ** ASMA044E Undefined symbol - SMF42FSN
> ** ASMA044E Undefined symbol - SMF42FDN
> ** ASMA044E Undefined symbol - SMF42FIR
> ** ASMA044E Undefined symbol - SMF42FIW
> ** ASMA044E Undefined symbol - SMF42FNL
> ** ASMA044E Undefined symbol - SMF42FFN
> ** ASMA044E Undefined symbol - SMF42FFN
> 
> I don't want to disable the RACF flag as I intend to use the features 
> enabled by it.
> Is it still required to set ST_DFSMS07 as a 'NO'?
> 
> – Vignesh
> Mainframe Infrastructure
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Anthony Thompson
> Sent: 17 May 2018 04:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB
> 
> I downloaded the latest DAF from the CBT site and assembled it, 
> without any serious problems. I turned off most options 
> (_ SETC C'000', also
> _DFSMS07 SETC 'NO ' to get it to assemble, as noted in the DAF comments).
> 
> I did not get an "Unknown Datatype x'011b'" if I provided DAF with 
> only SMF type 14/15, using a single control card of 'DATASET EQ  TSO userid>'. That message seems to be associated with processing SMF 
> type 80 records (RACF). I also avoided the same error if I excluded 
> RACF SMF records in DAF input but included all others. Curiously, I 
> still get that error message if I specify _RACF  SETC 'NO ' and 
> re-assemble DAF, and include type 80 SMF records in DAF input.
> 
> I also get a crapload of ' Unknown DataAUDAT=)' messages (not when
> using only SMF type14/15 as DAF input). I wish I had the time to 
> diagnose these DAF errors further.
> 
> Note I am on z/OS 2.3.
> 
> As for knowing whi

Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

[Anthony Thompson]

If all you are looking for is who has opened a dataset, SMF type 14 is all you 
should need.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Monday, 21 May 2018 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

Thanks Ant, wouldnt setting SMF42 off mean I can't use DATASET EQ  
stuff?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Monday 21-May-2018 06:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

Sorry for not responding earlier, I had Friday off.

SMF record 42 is for DFSMS statistics, so I avoided the SMF42* undefined 
symbols and the invalid R4 by setting _DFSMS to 0.

SMF record 82 is for ICSF, so I got rid of the SMF82ITE undefined symbol by 
_ICSF to 0.

And you still have to set _DFSMS07 to N for a clean assembly.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Friday, 18 May 2018 9:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

.. I have a compiled DAF from earlier which works for DATASET EQ stuff, but it 
doesn't recognize the RACF keywords, though I probably would have let the RACF 
flag default to a yes when I asm it years ago.

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: 18 May 2018 13:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

Hi Anthony,

Looks like I'm getting DAF assemble errors to now..

** ASMA044E Undefined symbol - SMF42S7
** ASMA044E Undefined symbol - SMF42FFS
** ASMA044E Undefined symbol - SMF42FTY
** ASMA044E Undefined symbol - SMF42FTM
** ASMA044E Undefined symbol - SMF42FSN
** ASMA044E Undefined symbol - SMF42FDN
** ASMA044E Undefined symbol - SMF42FIR
** ASMA044E Undefined symbol - SMF42FIW
** ASMA044E Undefined symbol - SMF42FNL
** ASMA044E Undefined symbol - SMF42FFN
** ASMA044E Undefined symbol - SMF42FFN

I don't want to disable the RACF flag as I intend to use the features enabled 
by it.
Is it still required to set ST_DFSMS07 as a 'NO'?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: 17 May 2018 04:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

I downloaded the latest DAF from the CBT site and assembled it, without any 
serious problems. I turned off most options (_ SETC C'000', also 
_DFSMS07 SETC 'NO ' to get it to assemble, as noted in the DAF comments).

I did not get an "Unknown Datatype x'011b'" if I provided DAF with only SMF 
type 14/15, using a single control card of 'DATASET EQ '. That 
message seems to be associated with processing SMF type 80 records (RACF). I 
also avoided the same error if I excluded RACF SMF records in DAF input but 
included all others. Curiously, I still get that error message if I specify 
_RACF  SETC 'NO ' and re-assemble DAF, and include type 80 SMF records in 
DAF input.

I also get a crapload of ' Unknown DataAUDAT=)' messages (not when 
using only SMF type14/15 as DAF input). I wish I had the time to diagnose these 
DAF errors further.

Note I am on z/OS 2.3.

As for knowing which jobs expand which PROCLIB members, I'm wondering if you 
can expose the IEFC001I message that usually appears in a job's JESYSMG dataset 
to SYSLOG/OPERLOG via a MPFLST member (that's the message that says this 
procedure / include group was expanded from this system / private library). 
Various automation products can also mess with route codes. Then you'd just 
need to scan a saved SYSLOG/OPERLOG to find out what you want to know.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Wednesday, 16 May 2018 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DAF (CBT 094) - Unknown Datatype x01BB

Has anyone seen on z/OS2.2 I see DAF is reporting "Unknown Datatype x01BB" and 
while downloading and assemble/linkedit latest CBT 094 gives me 0255 for 
various undefined symbol though I have checked the maclib .

anyone the point is has anyone recent ran DAF against SMF data for 14/15 for 
DATASET EQ  and got Unknown datatype message?


Also I know it's a separate topic but I have a requirement to know which procs 
are being expanded by which job from the proclib so trying to get that and 
PDSMAN do report a little for READ/BROWSE function against the members if it's 
enable to cut the smf record however doesn'

Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

[Anthony Thompson]

Sorry for not responding earlier, I had Friday off.

SMF record 42 is for DFSMS statistics, so I avoided the SMF42* undefined 
symbols and the invalid R4 by setting _DFSMS to 0.

SMF record 82 is for ICSF, so I got rid of the SMF82ITE undefined symbol by 
_ICSF to 0.

And you still have to set _DFSMS07 to N for a clean assembly.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Friday, 18 May 2018 9:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

.. I have a compiled DAF from earlier which works for DATASET EQ stuff, but it 
doesn't recognize the RACF keywords, though I probably would have let the RACF 
flag default to a yes when I asm it years ago.

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: 18 May 2018 13:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

Hi Anthony,

Looks like I'm getting DAF assemble errors to now..

** ASMA044E Undefined symbol - SMF42S7
** ASMA044E Undefined symbol - SMF42FFS
** ASMA044E Undefined symbol - SMF42FTY
** ASMA044E Undefined symbol - SMF42FTM
** ASMA044E Undefined symbol - SMF42FSN
** ASMA044E Undefined symbol - SMF42FDN
** ASMA044E Undefined symbol - SMF42FIR
** ASMA044E Undefined symbol - SMF42FIW
** ASMA044E Undefined symbol - SMF42FNL
** ASMA044E Undefined symbol - SMF42FFN
** ASMA044E Undefined symbol - SMF42FFN

I don't want to disable the RACF flag as I intend to use the features enabled 
by it.
Is it still required to set ST_DFSMS07 as a 'NO'?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: 17 May 2018 04:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: DAF (CBT 094) - Unknown Datatype x01BB

I downloaded the latest DAF from the CBT site and assembled it, without any 
serious problems. I turned off most options (_ SETC C'000', also 
_DFSMS07 SETC 'NO ' to get it to assemble, as noted in the DAF comments).

I did not get an "Unknown Datatype x'011b'" if I provided DAF with only SMF 
type 14/15, using a single control card of 'DATASET EQ '. That 
message seems to be associated with processing SMF type 80 records (RACF). I 
also avoided the same error if I excluded RACF SMF records in DAF input but 
included all others. Curiously, I still get that error message if I specify 
_RACF  SETC 'NO ' and re-assemble DAF, and include type 80 SMF records in 
DAF input.

I also get a crapload of ' Unknown DataAUDAT=)' messages (not when 
using only SMF type14/15 as DAF input). I wish I had the time to diagnose these 
DAF errors further.

Note I am on z/OS 2.3.

As for knowing which jobs expand which PROCLIB members, I'm wondering if you 
can expose the IEFC001I message that usually appears in a job's JESYSMG dataset 
to SYSLOG/OPERLOG via a MPFLST member (that's the message that says this 
procedure / include group was expanded from this system / private library). 
Various automation products can also mess with route codes. Then you'd just 
need to scan a saved SYSLOG/OPERLOG to find out what you want to know.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Wednesday, 16 May 2018 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DAF (CBT 094) - Unknown Datatype x01BB

Has anyone seen on z/OS2.2 I see DAF is reporting "Unknown Datatype x01BB" and 
while downloading and assemble/linkedit latest CBT 094 gives me 0255 for 
various undefined symbol though I have checked the maclib .

anyone the point is has anyone recent ran DAF against SMF data for 14/15 for 
DATASET EQ  and got Unknown datatype message?


Also I know it's a separate topic but I have a requirement to know which procs 
are being expanded by which job from the proclib so trying to get that and 
PDSMAN do report a little for READ/BROWSE function against the members if it's 
enable to cut the smf record however doesn't report correct job name...so if 
anybody also has idea if similar been in past a necessity for them to know and 
how they achieved it will be great to know as well.

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

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Whar

Re: DAF (CBT 094) - Unknown Datatype x01BB

[Anthony Thompson]

I downloaded the latest DAF from the CBT site and assembled it, without any 
serious problems. I turned off most options (_ SETC C'000', also 
_DFSMS07 SETC 'NO ' to get it to assemble, as noted in the DAF comments).

I did not get an "Unknown Datatype x'011b'" if I provided DAF with only SMF 
type 14/15, using a single control card of 'DATASET EQ '. That 
message seems to be associated with processing SMF type 80 records (RACF). I 
also avoided the same error if I excluded RACF SMF records in DAF input but 
included all others. Curiously, I still get that error message if I specify 
_RACF  SETC 'NO ' and re-assemble DAF, and include type 80 SMF records in 
DAF input.

I also get a crapload of ' Unknown DataAUDAT=)' messages (not when 
using only SMF type14/15 as DAF input). I wish I had the time to diagnose these 
DAF errors further.

Note I am on z/OS 2.3. 

As for knowing which jobs expand which PROCLIB members, I'm wondering if you 
can expose the IEFC001I message that usually appears in a job's JESYSMG dataset 
to SYSLOG/OPERLOG via a MPFLST member (that's the message that says this 
procedure / include group was expanded from this system / private library). 
Various automation products can also mess with route codes. Then you'd just 
need to scan a saved SYSLOG/OPERLOG to find out what you want to know.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Wednesday, 16 May 2018 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DAF (CBT 094) - Unknown Datatype x01BB

Has anyone seen on z/OS2.2 I see DAF is reporting "Unknown Datatype x01BB" and 
while downloading and assemble/linkedit latest CBT 094 gives me 0255 for 
various undefined symbol though I have checked the maclib .

anyone the point is has anyone recent ran DAF against SMF data for 14/15 for 
DATASET EQ  and got Unknown datatype message? 


Also I know it's a separate topic but I have a requirement to know which procs 
are being expanded by which job from the proclib so trying to get that and 
PDSMAN do report a little for READ/BROWSE function against the members if it's 
enable to cut the smf record however doesn't report correct job name...so if 
anybody also has idea if similar been in past a necessity for them to know and 
how they achieved it will be great to know as well.

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

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

Re: Any challenges with setting CSCBLOC to ABOVE

[Anthony Thompson]

The challenges are if you have any locally-written programs or 3rd-part 
vendor-supplied software that assume the CSCB (Command Step Control Block, 
generally used to implement started task operator commands) is in 24-bit 
storage. 

Either contact the vendor or test in a non-productive environment, such as a 
testplex.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, 2 May 2018 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any challenges with setting CSCBLOC to ABOVE

Just a curiosity.  Some shops are still coding CSCBLOC=BELOW but the default at
2.1 is ABOVE

Description under MAXUSER States:

However, too large a buffer can cause the system to allocate more system 
resources than are needed during a given IPL. The excessive allocation of 
system resources because of incorporating too large a buffer can lead to 
potential problems such as the following examples:

The specification of MAXUSER in conjunction with CSCBLOC=BELOW and RSVSTRT 
can cause the system to allocate excessive storage below 16 M. See CSCBLOC for 
additional details.
An aggressively large MAXUSER, RSVSTRT, and RSVNONR can cause the system to 
allocate an excessive amount of storage, which can potentially lead to a wait 
state 204 reason 008. (Wait state 204 with reason 008: An error occurred during 
allocation initialization; the system could not obtain storage for device
information.) The system enters a non-restartable wait state 204 at IPL time.




Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

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

Re: DFHSM Migration of SYS1 datasets ?

[Anthony Thompson]

Have you tried the rename-dataset-and-establish-alias I suggested? Maybe you 
don't have the necessary access authority to the dataset / master catalogue.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Wednesday, 28 March 2018 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migration of SYS1 datasets ?

So, why doesn't it work for me? It's not a big enough issue for me to try and 
open a PMR, especially since I probably need to route that through our MFaaS 
provider now!

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Anthony Thompson
> Sent: Tuesday, March 27, 2018 5:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migration of SYS1 datasets ?
> 
> Quite right Bart.
> 
> HSM V2.3 Impl & Cust Ch 4 (User Datasets) has Table 4 listing dataset 
> type support for space management functions. One of the entries in 
> that table says datasets starting with SYS1 or HSM won't get 
> command-migrated, but notes that the restriction can be over-ridden by SETMIG 
> LEVEL().  Page 62.
> 
> Same page number in the 2.1 version of the manual.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of van der Grijn, Bart (B)
> Sent: Wednesday, 28 March 2018 4:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migration of SYS1 datasets ?
> 
> I've never used the option, but the way I read the manual (z/OS 2.3), 
> it specifically requires the LEVEL parameter. I assume that means you 
> need to do a SETMIG for LEVEL(SYS1) rather than at the DATASETNAME level.
> I haven't tested this, it's just how I interpret the manual.
> FWIW,
> Bart
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: Tuesday, March 27, 2018 4:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migration of SYS1 datasets ?
> 
> This email originated from outside of the organization.
> 
> 
> And the SETMIG command's apparent  explicit purpose as  documented to 
> allow removing/reinstating this restriction by LEVEL or DATASETNAME.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 
> > Behalf Of Anthony Thompson
> > Sent: Monday, March 26, 2018 8:48 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM Migration of SYS1 datasets ?
> >
> > ARC1245I Reason Code 1:
> >
> > The data set is a system data set, a VSAM catalog, or an integrated 
> > catalog facility (ICF) catalog. Either the first four characters of 
> > the data set name are HSM, or the first five characters of the data 
> > set name are SYS1, or the data set name is SYSCTLG.
> >
> >
> > HSM does not process SYS1 datasets.
> >
> > If you are trying to migrate SYS1.PSF.FDEFLIB, that implies the 
> > dataset is generally not required by any of your started tasks or 
> > other
> processes.
> >
> > You could rename it to another HLQ, establish a SYS1.PSF.FDEFLIB 
> > alias for
> it.
> > Of course, the new datasetname would need to be catalogued in the 
> > master catalogue too.
> >
> > Ant.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > Sent: Tuesday, 27 March 2018 11:19 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: DFHSM Migration of SYS1 datasets ?
> >
> > I am at z/OS 2.1. I understand the need to make this hard, but what 
> > am I missing.
> > F DFHSM,SETMIG DATASETNAME(SYS1.PSF.FDEFLIB) COMMANDMIGRATION
> ARC0170I
> > SETMIG DSN SYS1.PSF.FDEFLIB PROCESSED
> > EJES510 LT01-GIBNEY--/F DFHSM,MIGRATE
> > DATASETNAME(SYS1.PSF.FDEFLIB) F DFHSM,MIGRATE
> > DATASETNAME(SYS1.PSF.FDEFLIB) ARC1001I SYS1.PSF.FDEFLIB MIGRATE 
> > FAILED, RC=0045, 051 ARC1001I (CONT.) REAS=0001 ARC1245I DATA SET
> NOT
> > ELIGIBLE FOR MIGRATION
> >
> > The documentation indicates that the SETMIG command should allow me 
> > to request DFHSM perform this migration. I've tried several 
> > varations using SETMIG LEVEL also. The volume where this dataset 
> > resides is Non-
> SMS.
> >
> > Yes, I know I can use ADRDSSU to move it, but not to M1 or ML2
> >
> > Does this function just not work? Or have  missed something obvious.
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >

Re: DFHSM Migration of SYS1 datasets ?

[Anthony Thompson]

Quite right Bart.

HSM V2.3 Impl & Cust Ch 4 (User Datasets) has Table 4 listing dataset type 
support for space management functions. One of the entries in that table says 
datasets starting with SYS1 or HSM won't get command-migrated, but notes that 
the restriction can be over-ridden by SETMIG LEVEL().  Page 62.

Same page number in the 2.1 version of the manual. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of van der Grijn, Bart (B)
Sent: Wednesday, 28 March 2018 4:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migration of SYS1 datasets ?

I've never used the option, but the way I read the manual (z/OS 2.3), it 
specifically requires the LEVEL parameter. I assume that means you need to do a 
SETMIG for LEVEL(SYS1) rather than at the DATASETNAME level. 
I haven't tested this, it's just how I interpret the manual. 
FWIW,
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Tuesday, March 27, 2018 4:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM Migration of SYS1 datasets ?

This email originated from outside of the organization.


And the SETMIG command's apparent  explicit purpose as  documented to allow 
removing/reinstating this restriction by LEVEL or DATASETNAME.

> -Original Message-
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On 
> Behalf Of Anthony Thompson
> Sent: Monday, March 26, 2018 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM Migration of SYS1 datasets ?
>
> ARC1245I Reason Code 1:
>
> The data set is a system data set, a VSAM catalog, or an integrated 
> catalog facility (ICF) catalog. Either the first four characters of 
> the data set name are HSM, or the first five characters of the data 
> set name are SYS1, or the data set name is SYSCTLG.
>
>
> HSM does not process SYS1 datasets.
>
> If you are trying to migrate SYS1.PSF.FDEFLIB, that implies the 
> dataset is generally not required by any of your started tasks or other 
> processes.
>
> You could rename it to another HLQ, establish a SYS1.PSF.FDEFLIB alias for it.
> Of course, the new datasetname would need to be catalogued in the 
> master catalogue too.
>
> Ant.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: Tuesday, 27 March 2018 11:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFHSM Migration of SYS1 datasets ?
>
> I am at z/OS 2.1. I understand the need to make this hard, but what am 
> I missing.
> F DFHSM,SETMIG DATASETNAME(SYS1.PSF.FDEFLIB) COMMANDMIGRATION ARC0170I 
> SETMIG DSN SYS1.PSF.FDEFLIB PROCESSED
> EJES510 LT01-GIBNEY--/F DFHSM,MIGRATE
> DATASETNAME(SYS1.PSF.FDEFLIB) F DFHSM,MIGRATE
> DATASETNAME(SYS1.PSF.FDEFLIB) ARC1001I SYS1.PSF.FDEFLIB MIGRATE 
> FAILED, RC=0045, 051 ARC1001I (CONT.) REAS=0001 ARC1245I DATA SET NOT 
> ELIGIBLE FOR MIGRATION
>
> The documentation indicates that the SETMIG command should allow me to 
> request DFHSM perform this migration. I've tried several varations 
> using SETMIG LEVEL also. The volume where this dataset resides is Non-SMS.
>
> Yes, I know I can use ADRDSSU to move it, but not to M1 or ML2
>
> Does this function just not work? Or have  missed something obvious.
>
> Dave Gibney
> Information Technology Services
> Washington State University
>
>

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

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

Re: DFHSM Migration of SYS1 datasets ?

[Anthony Thompson]

ARC1245I Reason Code 1:

The data set is a system data set, a VSAM catalog, or an integrated
catalog facility (ICF) catalog. Either the first four characters of
the data set name are HSM, or the first five characters of the data
set name are SYS1, or the data set name is SYSCTLG.


HSM does not process SYS1 datasets.

If you are trying to migrate SYS1.PSF.FDEFLIB, that implies the dataset is 
generally not required by any of your started tasks or other processes.

You could rename it to another HLQ, establish a SYS1.PSF.FDEFLIB alias for it. 
Of course, the new datasetname would need to be catalogued in the master 
catalogue too.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Tuesday, 27 March 2018 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM Migration of SYS1 datasets ?

I am at z/OS 2.1. I understand the need to make this hard, but what am I 
missing.
F DFHSM,SETMIG DATASETNAME(SYS1.PSF.FDEFLIB) COMMANDMIGRATION ARC0170I SETMIG 
DSN SYS1.PSF.FDEFLIB PROCESSED
EJES510 LT01-GIBNEY--/F DFHSM,MIGRATE DATASETNAME(SYS1.PSF.FDEFLIB) F 
DFHSM,MIGRATE DATASETNAME(SYS1.PSF.FDEFLIB) ARC1001I SYS1.PSF.FDEFLIB MIGRATE 
FAILED, RC=0045, 051 ARC1001I (CONT.) REAS=0001 ARC1245I DATA SET NOT ELIGIBLE 
FOR MIGRATION

The documentation indicates that the SETMIG command should allow me to request 
DFHSM perform this migration. I've tried several varations using SETMIG LEVEL 
also. The volume where this dataset resides is Non-SMS.

Yes, I know I can use ADRDSSU to move it, but not to M1 or ML2

Does this function just not work? Or have  missed something obvious.

Dave Gibney
Information Technology Services
Washington State University


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

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

Re: PDSCLEAN issue

[Anthony Thompson]

Oops, typo... z/OS 1.8

Sorry, Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, 18 January 2018 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

My understanding is that the problem with deleting PDSE's after they have been 
in linklist, even after being removed from the currently active linklist set, 
was fixed in z/OS 1. See OW57609.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beesley, Paul
Sent: Thursday, 18 January 2018 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

No, Allan is right. LNKLST can include PDSE datasets but they seem to be 
managed differently to those added after IPL. They can't be deleted even after 
going through the Linklist unallocate palaver, and it seems they can't be 
emptied effectively.

BTW, someone suggested DELETE PDSE(*) but that doesn't work for Linklist 
datasets as they are in use by LLA (although I haven't tried stopping LLA)

Regards and thanks
Paul

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, January 17, 2018 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Atos, Atos Consulting, 
Worldline and Canopy The Open Cloud Company are trading names used by the Atos 
group. The following trading entities are registered in England and Wales: Atos 
IT Services UK Limited (registered number 01245534), Atos Consulting Limited 
(registered number 04312380), Atos Worldline UK Limited (registered number 
08514184) and Canopy The Open Cloud Company Limited (registration number 
08011902). The registered office for each is at 4 Triton Square, Regent’s 
Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

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

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

Re: PDSCLEAN issue

[Anthony Thompson]

My understanding is that the problem with deleting PDSE's after they have been 
in linklist, even after being removed from the currently active linklist set, 
was fixed in z/OS 1. See OW57609.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beesley, Paul
Sent: Thursday, 18 January 2018 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

No, Allan is right. LNKLST can include PDSE datasets but they seem to be 
managed differently to those added after IPL. They can't be deleted even after 
going through the Linklist unallocate palaver, and it seems they can't be 
emptied effectively.

BTW, someone suggested DELETE PDSE(*) but that doesn't work for Linklist 
datasets as they are in use by LLA (although I haven't tried stopping LLA)

Regards and thanks
Paul

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, January 17, 2018 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Atos, Atos Consulting, 
Worldline and Canopy The Open Cloud Company are trading names used by the Atos 
group. The following trading entities are registered in England and Wales: Atos 
IT Services UK Limited (registered number 01245534), Atos Consulting Limited 
(registered number 04312380), Atos Worldline UK Limited (registered number 
08514184) and Canopy The Open Cloud Company Limited (registration number 
08011902). The registered office for each is at 4 Triton Square, Regent’s 
Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

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

Re: PDSCLEAN issue

[Anthony Thompson]

That's not true. If there were any such restriction, it would be documented in 
the Init and Tuning Reference. We have both non-SMS managed and SMS-managed 
PDSE's in our IPL-time linklist, without any problems.

These days, IBM ship two linklist-required datasets as PDSE's (SIEALNKE and 
SIEAMIGE).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Wednesday, 17 January 2018 1:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

The only restriction I am aware of is that the PDSE cannot be in the IPL time 
LINKLIST. It can be added after IPL.

This is due to the fact that SMS is not yet initialized at the time the IPL 
LINKLIST is buir.

HTH

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beesley, Paul
Sent: Tuesday, January 16, 2018 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PDSCLEAN issue

I have been using the PDSCLEAN program from the CBT tape file 693 for a while 
and think it’s great, but have a quick question.
Is there an issue using this on PDSEs in the Linklist?
On 2 occasions now I have used it to zero a linklisted PDSE (Compuware’s 
SLCXLOAD if it’s important, and on a test system, I hasten to add) with the 
intention of copying in some maintenance from the SMPE version and it has been 
unsuccessful.
The report says the PDSE has been cleared, and indeed there are 0 members, 
however an ISPF 3.4 display shows that the percentage used hasn’t gone down 
from the original 67% used. I tried the process on a copy of the PDSE and it 
worked fine … 0 members and 0% used. I can only assume it’s because LLA has 
hold of it or something.

( I did sent the above to the author but the email bounced back)

Regards and thanks
Paul



Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

Re: SAS - DB2 conversion to Java

[Anthony Thompson]

http://s3-us-west-1.amazonaws.com/watsonwalker/ww/wp-content/uploads/2016/03/28073651/Spark-and-SMF.pdf

Timothy Sipples may have more to add.

Cheers, Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Wednesday, 29 November 2017 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SAS - DB2 conversion to Java

On 29/11/2017 10:08 AM, Anthony Thompson wrote:
> What about Spark on Z? IBM are giving it away.
>
I haven't tried it, but from the documentation and presentations it seems 
pretty heavyweight for simple SMF reporting.

I see a couple of other issues:
- IBM were saying how great it was at parallelizing work, however that is a bit 
of a red flag for me. Parallelizing is great if you have e.g. a multi core 
workstation where you hit 100% usage on one core while the others are idle. 
That isn't usually the case on z/OS. Most z/OS customers would prefer speeding 
up by reducing total CPU usage than spreading it across multiple CPUs. It would 
be fairly uncommon on z/OS for this type of job to run at a priority where 
single CPU capacity is the limiting factor.
- I think the reporting is SQL based? SMF data was not designed to be queried 
using SQL. I have been down that path. On the other hand, Java classes are 
beautiful for working with SMF data (not quite as nice as C# but still very 
good).

--
Andrew Rowley
Black Hill Software

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

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

Re: SAS - DB2 conversion to Java

[Anthony Thompson]

What about Spark on Z? IBM are giving it away.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Tuesday, 28 November 2017 9:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SAS - DB2 conversion to Java

On 24/11/2017 2:50 AM, Barry Merrill wrote:
> I'd also be VERY concerned about the execution time if your 
> applications are high volume under Java versus under SAS.

I only know SAS by reputation, but my expectation would be the opposite
- I would expect Java to be faster than SAS. I suspect (but haven't been able 
to measure definitively) that it costs more CPU in TCPIP to FTP the data than 
to run Java reports on the mainframe - and the Java CPU time is on zIIP.

What sort of SMF volumes and processing speeds are typical? I'm currently 
playing with transaction reporting from CICS monitoring data. 
On my PC, summarizing data by region and transaction name takes about 45 
seconds for around 12 million transactions from compressed CICS data. On the 
IBM remote development system, about 25 CPU seconds (almost all
zIIP) for 2.5 million transactions (I am limited by DASD space so am working on 
smaller files).

I feel like this is fast but would welcome feedback based on real world data.

--
Andrew Rowley
Black Hill Software

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

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

Re: ARC0734i rc=20 reason=98

[Anthony Thompson]

You might look at SMF record 65's (catalogue delete) to find out what process 
is messing with your GDG's.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Tuesday, 21 November 2017 6:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ARC0734i rc=20 reason=98

The MC is set to EXPIRE. And that's the other strange thing, not all GDGs that 
share the MC have the same problem.


Hervey



From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Monday, November 20, 2017 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ARC0734i rc=20 reason=98

GDS=EXPIRED vs GDS=MIGRATE in the SMS management class?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Monday, November 20, 2017 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ARC0734i rc=20 reason=98

Well, all files that I've seen are GDG files. This is very puzzling. There are 
a few of these errors that happen every so often but have no idea what is 
causing them.


Hervey



From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Monday, November 20, 2017 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ARC0734i rc=20 reason=98

Non-symetric aliases? i.e. alias A in MCATA, but not in MCATB

See message arc1220I RC=98 for explanation.

Basically get down to one copy of the dataset (whether it is the migrated copy 
or the "real" dataset).
This will resolve the issue.

As to why, there are too many variables to spend a great deal of time 
speculating.

HTH,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Monday, November 20, 2017 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ARC0734i rc=20 reason=98

We have several datasets that show up in HSM's miglog file. I know the problem 
is that the file is not cataloged and is the reason for the error. My question 
is: What causes these files to become uncataloged?

I've read a few other posts about the HSM address space being cancelled due to 
errors and causing this sort of error. We only recycle HSM during maintenance 
on the weekends and many of these errors happen during the week which does not 
coincide with the recycling of the HSM task.

Any ideas?

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
may contain viruses in transmission. The e mail and its contents (with or 
without referred errors) shall therefore not attach any liability on the 
originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the views or opinions of HCL or its 
affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in error please delete it and 
notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

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

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

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

Re: non-ibm products in /service ?

[Anthony Thompson]

That's exactly what I prefer.

/service has its own filesystem, used purely to hold the directory entries for 
IBM and non-IBM directories/objects, which are all stored in their own mounted 
filesystems.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Monday, 16 October 2017 3:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: non-ibm products in /service ?

>What is the recommendation regarding having non-ibm products mounted in 
>/service ? 


When it comes to IBM SMP/E managed parts, you change the DDDEF path by 
prefixing it with /service. So /bin becomes /service/bin. 
However, I see no reason why you cannot expand on that and build some 
subdirectories in /service, say /service/ibm/zos, /service/ibm/db2, 
/service/somevendor/someproduct, etc. as mount points for the corresponding 
service file systems. Then adjust the DDDEFs accordingly, or for non-SMP/E 
products adjust the install script, install job or whatever.


--
Peter Hunkeler 



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

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

Re: DLIB volume for SAD

[Anthony Thompson]

Your question implies confusion.

It is the Stand-Alone Dump program that scans and saves a broken LPAR's memory, 
which you IPL on top of a broken LPAR. I imagine you can scan a broken LPAR's 
memory using HMC/SE facilities, but I doubt many people can "PEEK/POKE" a 
busted-arse LPAR to fix it on the fly successfully.  Generally you want the 
system back up as soon as possible (take SAD and re-boot).

The fact that you SAD program has been installed on the volume that contains 
your DLIB's is irrelevant. There are no DLIB's or programs from DLIB's involved 
in the process of a stand-alone dump. It is the installation of the SAD program 
that generates all the necessary components, on whatever tape or DASD volume 
you specify (excluding any DASD sysres volumes of course, you don't want to 
overwrite the IPL text stored in cyl 0,0 that brings up your system).

Refer to the MVS Diagnosis and Service Aids manual for whichever version of 
z/OS you are using.

Ant.
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Friday, 29 September 2017 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DLIB volume for SAD

Is there a scanning mechanism within Distribution library dataset to scan the 
memory of frozen Lpar ?

On 29-Sep-2017 7:11 AM, "Ed Jaffe"  wrote:

> On 9/27/2017 2:16 PM, Steely.Mark wrote:
>
>> A little off topic - when is the last time anyone  had  to perform a 
>> SAD ?  I haven’t done one in 20+ years.
>>
>
> We take a SAD every time any of our systems go south.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: SYS3 datasets

[Anthony Thompson]

I've worked at a few different shops, and I've seen that SYS2, SYS3, SYS4 HLQ 
convention a several times.

It's a hangover from days of yore, around about the 10th century CE, when 
link-listed datasets had to be catalogued in the master catalogue. The thinking 
went: since SYS1 files are catalogued in the master catalogue for IBM datasets, 
let's create SYSx HLQ's for non-IBM datasets that need to be in the master 
catalogue too. Not necessary in these enlightened times of course, but those 
original conventions tend to hang around.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Tuesday, 26 September 2017 12:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYS3 datasets

> On Sep 25, 2017, at 6:20 AM, van der Grijn, Bart (B)  
> wrote:
> 
> 
> We have a staff z/OS systems programmer who claims that:
> "Almost all shops use the SYS3. HLQ to indicate third party software."
> 
> So new software installs *have* to follow that "rule". (Past installs 
> did not follow such a rule.)
> 
> I am thinking that this "rule" is really just *his* rule.
> 
> Opinions?
> 
> How many other sites follow such a rule?
> 
> --
> Tony Thigpen

Tony,
We started out in that direction, but found that some vendors products *HAD* to 
be in the linklst. I refused to put a sys3 dataset in the linkliest PERIOD. One 
of the reasons was that there would be a plethora  of datasets and there was no 
accounting of who put this where and why.
That got stopped after a year. I also didn’t want people that left any dirt 
they may have left either by accident or on purpose anything in the linklst (I 
won’t tell you about an incident we had that when the auditors found out they 
jumped on us up and down to get rid of them. I agreed but they wanted it done 
today and I said maybe next week as we had something major going in (it was 30+ 
years ago and I don’t remember details).

Ed


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

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

Re: Keeping SSN init modules current

[Anthony Thompson]

Beat me to it. I was going to suggest a ++MOVE usermod, provided the SSI module 
is SMP/E-maintained.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, 21 September 2017 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping SSN init modules current

In poking around our stable of usermods, I find this usermod for ISPF:

++USERMOD (ISPF003) REWORK(20141710) . 
++VER (Z038)  FMID (HIF7N02) . 
++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD .
..

The point of this IBM-suggested usermod is to move SCLM modules from LPA to 
link list for shops that don't utilize SCLM heavily. What if we created 
something like this:

++USERMOD (HSC) REWORK(date) . 
++VER (Z038)  FMID (hsc-fmid) . 
++MOVE (ssn-init-module) SYSLIB(hsc-loadlib) TOSYSLIB(LINKLIB) LMOD .

where LINKLIB is SYS1.LINKLIB. 

Future HSC maintenance, if any, would find the module in SYS1.LINKLIB and keep 
it up to date until the next upgrade, which would require reAPPLYing the 
usermod.


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Wednesday, September 20, 2017 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping SSN init modules current

I was thinking of similar craziness, but I'd replace the actual HSC init 
program with my own.  Then like you implied, that code would dynamically 
allocate the DSN and do a LOAD DCB= to get the real module into memory. 
  Then deallocate, restore registers (to what they were at entry), branch, and 
"The OS will never know" (famous last words).

This method would also mean following a convention I've argued for over many 
years:  "Never use version numbers in production load library names".

Ok!  Now back to the real world and just go update the doc :)

Mark Jacobs - Listserv wrote:
> Here's a wild thought. Create your own dummy subsystem with its own 
> initialization routine that gets executed before any of the subsystems 
> you're concerned about. This initialization routine can load the other 
> modules into CSA, or even copy from one library to a linklist library.
> We have an installation defined dummy subsystem that uses the 
> initialization routine to define system level name/token pairs during 
> the IPL process.
> 


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

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Anthony Thompson]

Is it possible that it is ROSCOE (alternative to TSO) that your lonely last 
brain cell is trying to remember?

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Friday, 30 June 2017 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast 
for ever)

It really was a long time ago, but I think only one TSO user was swapped in at 
a time within each region.  (There were TSEVENTs then, much like SYSEVENTs 
now).  

Caveat:  I'm pretty much down to my last brain cell, so I could be 
misremembering.  I spent 50 years in this business;  the knowledge is still in 
my head but the table of contents and the index are both shot.  YMMV!  

> On Jun 29, 2017, at 16:09, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> What, then, was the scope of an allocation?  Of an ENQ?  What happened 
> if multiple users concurrently ALLOCATEd SYSUT2?  I suppose carefully 
> avoiding RET=HAVE could keep the DSN spaces separate.  And users would 
> just need to deal with that and the "IKJ56246I type_name NOT ALLOCATED, FILE 
> IN USE"
> condition.

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

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

Re: Logstreams

[Anthony Thompson]

Just so. We start up our systems on SYS1.LOGREC and convert to logstream once 
logger services are available (SETLOGRC command issued via automation).

I converted both SMF and SYSLOG to logstreams with no dramas. This site had 
syslogs stored by system-id, so I modified SAMPLIB(IEAMDBLG) to filter/save 
OPERLOG by sys-id to maintain the saved syslog GDG's that were inspected by 
other processes.  

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, 29 June 2017 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

We don't run regularly with logrec logstream, but I believe that you still need 
to maintain SYS1.LOGREC in order to capture IPL time records that are cut 
before logger gets running. If that's still true...

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pew, Curtis G
Sent: Wednesday, June 28, 2017 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

On Jun 28, 2017, at 2:07 PM, Bill Wilkie  wrote:
> 
> Is anyone running from logstreams instead just running logrec? Using 
> logstreams for other reports? How used? Problems?

I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went 
smoothly and without issues.

--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

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

Re: changing batch job to use SSL

[Anthony Thompson]

I will also note that z/OSMF provides a Configuration Assistant that can help 
set up AT/TLS, which might be easier for first-time exploiters of TLS.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Friday, 16 June 2017 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: changing batch job to use SSL

Andrew,

The mechanics are pretty basic, at least conceptually. AT-TLS (in 
Communications Server for z/OS) supports both TLS/SSL server certificate 
authentication and TLS/SSL client certificate authentication. The Policy Agent 
configuration is what decides which authentication(s) apply.

If you'd like an introduction to how this all works, this one is fairly good, 
although it's slightly dated (written/recorded about 6 years ago):

https://www.ibm.com/support/docview.wss?uid=swg27028558

As a reminder, IPsec is another potential option. It depends on what you're 
trying to accomplish, but both approaches have their roles.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: LE QuestionT - now CICS

[Anthony Thompson]

STGPROT in the CICS SIT, telling CICS that various Dynamic Storage Areas should 
be allocated in CICS or user key storage. Also dependent parameters TRANISO, 
RENTPGM, TCTUAKEY, CWAKEY.

I think storage protection came in around CICS/ESA 3.3 (early 90's).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Friday, 9 June 2017 1:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE QuestionT - now CICS

> On Jun 8, 2017, at 7:49 AM, Peter Relson  wrote:
> SNIP———

Peter, good answer.
This reminds me a little of something long long ago. Maybe someone here can 
refresh (correct?) my memory.
From the time CICS came out the sysprogs were always seemingly fighting storage 
overlays (if memory serves me).
After 5-8 years?? CICS’s answer was to use different storage keys to isolate 
and prevent storage overlays.
Can someone correct my memory of this, please?

Ed

> Tony H's response was right on target. Using different user-region 
> subpools does nothing to help prevent overwrites or corruption.
> It does help a bit with someone unintentionally freeing the wrong thing.
> Some applications might choose unique subpools to accommodate a 
> subpool freemain.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: you can request improvements to IBM Knowledge Center using the RFE process now

[Anthony Thompson]

KC can be installed locally, with reduced functionality, as of z/OS 2.2. You 
don't have to depend on IBM servers.

I've said it before, and I'll say it again. The BIG advantage to KC is that it 
is web-searchable, unlike the majority of third-party mainframe (and other 
platforms) software products' documentation.

And having said that, I vastly prefer PDF's. Much easier to scroll through.

Ant.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, 23 May 2017 10:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: you can request improvements to IBM Knowledge Center using the RFE 
process now

On Tue, May 23, 2017 at 7:49 AM, Allan Staller 
wrote:

> Actually, KC seems to be one of the better of the "new tools".
>
> However, the new tools are neither as reliable, functional, nor 
> (especially)available as the tools they are replacing.
>
> Once IBM get out of the mindset that "It's OK to take down the support 
> portal for 24 hours, during the prime customer outage window" I might 
> back off on this stance.
>
> The RAS for the support systems needs to be as least on the same order 
> of magnitude as the systems they are supporting.
> The tools and mechanisms to provide this RAS are available, certainly 
> on *IX and (possibly) Windoze.
> IBM needs to exploit the mechanisms.
>

​Or as with what happened to me yesterday. I'm reading something. I click on 
the arrow to go to the next page. The site gets an 503 (Server
Unavailable) for I don't know how long. Longer than my cursing out IBM and KC. 
And, no I cannot download the entire KC for all the products I need. I don't 
have a big enough local drive and the SAN people send dunning emails if your 
personal share takes up "too much space" for "unnecessary" (in their opinion) 
files.​


--
Windows. A funny name for a operating system that doesn't let you see anything.

Maranatha! <><
John McKown

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

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

Re: Do you use CA-ACF2 and CICS or IMS? Be aware your CICS/IMS developers have security admin priviledges and can do whatever they want to the ACF2 database.

[Anthony Thompson]

Muilti-User Single Address Space System.

Pretty much what it says. It's an ACF2 term that refers to things like CICS.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, 6 April 2017 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Do you use CA-ACF2 and CICS or IMS? Be aware your CICS/IMS 
developers have security admin priviledges and can do whatever they want to the 
ACF2 database.

> It's either APF authorization or running in a MUSASS address space, the 
> second one is the problem. 
 

Pardon my ignorance, but can you explain in a few words what a MUSASS address 
space is?




--
Peter Hunkeler



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

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

Re: VSAM Extended addressing

[Anthony Thompson]

Use the TESTCB macro:

 TESTCB   ACB=,ATRB=XADDR

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Monika Amiss
Sent: Sunday, 2 April 2017 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VSAM Extended addressing

Dear Group.

In my assembler program I want to get aware if my opened vsam dataset is 
defined for extended addressing (>4GB) or not. How can I do this. Any hint 
appreciated

With best regards
Monika

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

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

Re: Spool file

[Anthony Thompson]

Of course, you know that implementing a change to the SPOOLDEF VOLUME parameter 
requires a cold start of JES2? And, unless you're not interested in keeping any 
of the old spool data, a spool offload/reload.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Thursday, 23 March 2017 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Spool file

My parmlib member points to SPOOL as the volume but everything else shows B2SYS.

SDSF SPOOL DISPLAY S0W1   2% ACT  14095 FRE  13683 LINE 1-2 (2)

 COMMAND INPUT ===>SCROLL ===>
CSR  
 NP   NAME   Status   TGPct TGNum TGUse Command  SAff  Ext LoCylLoTrk

  B2SYS1 ACTIVE   5  3000   164  ANY   00  031B

  B2SYS2 ACTIVE   2 11095   248  ANY   01  0006
  

3.4 Display
DSLIST - Data Sets on volume SPOOL* Row 1 of
6 
Command ===>  Scroll ===>
PAGE 
 

Command - Enter "/" to select action  Message
Volume

---
 SYS1.HASPACE
SPOOL1 
 SYS1.HASPACE
SPOOL2 
 SYS1.HASPACE
SPOOL3 
 SYS1.VTOCIX.SPOOL1
SPOOL1 
 SYS1.VTOCIX.SPOOL2
SPOOL2 
 SYS1.VTOCIX.SPOOL3
SPOOL3
* End of Data Set list

 





  $dspool,long  
  $HASP893 VOLUME(B2SYS1)   
VOLUME(B2SYS1)  STATUS=ACTIVE,DSNAME=SYS1.HASPACE,  
SYSAFF=(ANY),TGNUM=3000,TGINUSE=164,
TRKPERTGB=3,PERCENT=5,RESERVED=NO,  
MAPTARGET=NO
  $HASP893 VOLUME(B2SYS2)   
VOLUME(B2SYS2)  STATUS=ACTIVE,DSNAME=SYS1DisplKCELL=3,VOLUME=B2SYS

  $DSPOLLDEF   

JES parmlib member

SPOOLDEF BUFSIZE=3856,   /* MAXIMUM BUFFER SIZEc*/
 DSNAME=SYS1.HASPACE, 
 FENCE=NO,   /* Don't Force to Min.Vol. oc*/
 SPOOLNUM=32,/* Max. Num. Spool Vols--- c*
 TGBPERVL=5, /* Track Groups per volume in BLOB  ownc*
 TGSIZE=33,  /* 30 BUFFERS/TRACK GROUPwnc*/
 TGSPACE=(MAX=26288, /* Fits TGMs into 4K Page  =(,  c*/
  WARN=80),  /*   =(,% onc*/
 TRKCELL=3,  /* 3 Buffers/Track-cell   c*/
 VOLUME=SPOOL/* SPOOL VOLUME SERIALc*/
<---
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, March 22, 2017 12:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Spool file

Only one HASPACE per JES2 Spool volume

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, March 21, 2017 8:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Spool file
> 
> Issue a $DSPOOL,LONG  and see what it shows
> 
> Issue $DSPOOLDEF and see what it shows
> 
> Next go to ISPF 3.4
> 
> Search
> 
> **   in the dataset level
> SPOOL*  in the VOLSER and see what it shows
> 
> I am not clear about your statement:   The spool volumes are still on the
same
> pack.  Please provide a display of what you are seeing.
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman
> > Sent: Tuesday, March 21, 2017 7:48 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: Spool file
> >
> > I have 3 vols SPOOL1 SPOOL2 and SPOOL3
> >
> > In jes2 parmlib member on the spool def for volume I specify SPOOL 
> > and yet after ipl'ing
> >
> > And then going back to SDSF to look for the  spool volumes are on 
> > still on the same pack
> >
> >
> >
> > > On Mar 21, 2017, at 11:20 AM, Lizette Koehler 
> > >  >
> > wrote:
> > >
> > > The best practice for JES2 Spool file is standalone.  Never put 
> > > anything on the same volume as either the SPOOL Space or the CKPT
> datasets.
> > >
> > > That can lead to unintentional issues.
> > >
> > > Many shops in the past have tended towards multi-use volumes with 
> > > JES2.  This is not recommended.
> > >
> > > With storage arrays, you can code a volume as a MOD9 (9GB, 10,017
> > > Cylinders) and only place the ckpt or the spool space (not both) 
> > > on it. The array will typically only hold the amount of storage on 
> > > the
> > > mod9 as is allocated.  It does not hold the entire 10,017 
> > > cylinders 

Re: Maximum size of a PDSE library?

[Anthony Thompson]

There was a Redbook entitled 'Partitioned Data Set Extended Usage Guide', 
document number SG24-6106-01, dated May 2005 (so it very much pre-dated PDSE 
V2).

That Redbook stated that that PDSE directories entries were organised in a 
balanced B-tree, and that the PDSE pages were either directory pages, or data 
pages, not mixed. That information may no longer be accurate, of course.

I say was, as I searched on the Redbooks site in an effort to provide a link, 
using both the document title and number as search terms, but didn't find it. 

Ant.

-Original Message-

Subject: Re: Maximum size of a PDSE library?

On Tue, 21 Feb 2017 00:10:42 -0600, Barbara Nitz wrote:
>
>I believe that inserting an entry is just finding the place where it belongs 
>and adjusting the previous and next pointer(s).
> 
IOW you believe its a linear linked list rather than such as a B-tree?

Ouch.

Are the directories for PDSEv1, PDSEv2, HFS, and ZFS similarly organized?

Probably NDA.

>As for caching: The SMSPDSE1 address space used to cache the 4K blocks. Which 
>did not help at all, because back then the maximum cache available to SMSPDSE1 
>was 16GB (I believe). We had about 10 of those large VB PDSE's, and together 
>they were much bigger than the available cache, and SMSPDSE1 would cache the 
>full 4K (which includes data). ...
>
You suggest directory blocks contain data?  That would seem to optimize space 
utilization at the expense of performance.  And gain little except for quite 
small members.

And if I NOTE at the millionth record of the thousandth member of a VB PDSE and 
later POINT to it, I wonder what processing occurs?

Probably NDA.

-- gil

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

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

Re: I/O error substituting symbols in sysin

[Anthony Thompson]

Pardon for getting the input wrong. New JCL: 
//
//  EXPORT SYMLIST=*
//  SET TEST='THIS IS THE VALUE OF THE SUBSTITUTED STRING.' 
//STEP1EXEC PGM=IEBGENER
//SYSUT1   DD   DATA,SYMBOLS=JCLONLY,DCB=LRECL=222  
  This is a test of symbol use in instream data sets. Test here: 
/*  
//SYSUT2   DD   SYSOUT=(,)  
//SYSPRINT DD   SYSOUT=(,)  
//SYSINDD   DUMMY   

I'm supposing you used the TSO SUBMIT command to submit the job. A foible of 
TSO SUBMIT is that it doesn't do input greater than 80 characters. 

So you've got an 80-byte SYSUT1 input but you're telling the system it's really 
222 bytes. Bang. I/O error.

I put the same JCL above into a dataset with LRECL 222 and submitted it to an 
internal reader via IEBGENER (ICEGENER). Job Finished with RC 0.  

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, 13 December 2016 1:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O error substituting symbols in sysin

On 2016-12-12, at 00:56, Anthony Thompson wrote:

> Ran this JCL :
> 
> //
> //  EXPORT SYMLIST=*   
> //  SET TEST='THIS IS THE VALUE OF THE SUBSTITUTED STRING.'
> //STEP1EXEC  PGM=IEBGENER  
> //SYSUT1DD  DATA,SYMBOLS=JCLONLY   
> 
> /* 
> //SYSUT2DD  SYSOUT=(,) 
> //SYSPRINT  DD  SYSOUT=(,) 
> //SYSIN DD  DUMMY  
> 
> Only removed the DCB on SYSUT1. Job worked.
> 
Than's not "only".  You also changed the content of SYSUT1 in my example.  Try 
it with the SYSUT1 I cited, with or without DCB:

//SYSUT1DD  *,SYMBOLS=JCLONLY,DCB=LRECL=222
   This is a test of symbol use in instream data sets.   Test here: 


On 2016-12-12, at 02:50, Anthony Thompson wrote:

> Just so. But anyone can frig around with invalid DCB's and make any utility 
> break.

What do you claim was invalid about my DCB.  Cite Reference.

-- gil

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

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

Re: I/O error substituting symbols in sysin

[Anthony Thompson]

Just so. But anyone can frig around with invalid DCB's and make any utility 
break.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Monday, 12 December 2016 7:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O error substituting symbols in sysin

So that would be an ordinary 80-byte SYSIN, data within 80 bytes. Not what Paul 
is trying.

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

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

Re: I/O error substituting symbols in sysin

[Anthony Thompson]

Ran this JCL :

//
//  EXPORT SYMLIST=*   
//  SET TEST='THIS IS THE VALUE OF THE SUBSTITUTED STRING.'
//STEP1EXEC  PGM=IEBGENER  
//SYSUT1DD  DATA,SYMBOLS=JCLONLY   
  
/* 
//SYSUT2DD  SYSOUT=(,) 
//SYSPRINT  DD  SYSOUT=(,) 
//SYSIN DD  DUMMY  

Only removed the DCB on SYSUT1. Job worked.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, 10 December 2016 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O error substituting symbols in sysin

On Fri, 9 Dec 2016 09:47:17 -0700, Lizette Koehler wrote:

>What does your SYSUT2 DD statement look like?
>Typically SYSUT1 is copied to SYSUT2 JCL statements.
>I only see SYSUT1
> 
The problem occured on SYSUT1 and the message mentioned SYSUT1.
I don't believe it ever wrote  to SYSUT2, so I abbreviated.  More  fully:

//  EXPORT SYMLIST=*
//  SET TEST='This is the value of the substituted string.'
//STEP1EXEC  PGM=IEBGENER
//SYSUT1DD  DATA,SYMBOLS=JCLONLY,DCB=LRECL=222
This is a test of symbol use in instream data sets.  Test here: 
/*  This is a test of symbol use in instream data sets.  Test here: This is the
/*
//SYSUT2DD  SYSOUT=(,)
//SYSPRINT  DD  SYSOUT=(,)
//SYSIN DD  DUMMY

If you believe a different specification of SYSUT2 changes the behavior, I'd 
welcome the information.

>And if you need to raise an SR it would be to DFSMS Utilities.
>
Thanks, but does this seem to be a Utilities problem?

>> -Original Message-
>> From:  Paul Gilmartin
>> Sent: Friday, December 09, 2016 9:40 AM
>>...
>> Fails with SYSPRINT containing:
>>
>> 1DATA SET UTILITY - GENERATE
>> PAGE 0001
>> -IEB352I WARNING: ONE OR MORE OF THE OUTPUT DCB PARMS COPIED FROM INPUT
>>  IEB351I I/O ERROR ,JCLSYM  ,STEP1   ,JES ,D,SYSUT1  ,READ  ,WRONG LEN
>> RECRD,**,BSAM

Thanks again,
gil

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

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

Re: zOSMF and CMF?

[Anthony Thompson]

Of course, z/OSMF doesn't access RMF records directly. It interfaces to RMF 
facilities that present performance information for Z/OSMF to display.

Similarly with CMF. z/OSMF interfaces to BMC's Mainview to present performance 
information.

See here:  https://communities.bmc.com/docs/DOC-21208

Ant. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Norman Hollander on Desertwiz
Sent: Thursday, 8 December 2016 3:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and CMF?

IIRC, about 95% of the record data is the same.  Has anyone tried chatting with 
CMF Support at BMC?
zN

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barry Merrill
Sent: Wednesday, December 7, 2016 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF and CMF?

The only difference in the CMF and RMF SMF records is the value in the PRODUCT 
name in CMF is either CMF-CPM or CMF-IPF.

But I don't know if those records are accepted by zOSMF.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Tuesday, December 6, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF and CMF?

Does anyone know if CMF can interface with the zOSMF Performance modules in 
place of RMF?

I've not found anything in the CMF pubs (so far)

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


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

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

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

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

Re: SUPRESSING MESSAGES - DFHSM

[Anthony Thompson]

What about:

SETSYS ACTLOGMSGLVL(EXCEPTIONONLY)

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Tuesday, 8 November 2016 9:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUPRESSING MESSAGES - DFHSM

Sorry I should have stated my question more clearly.  In the HSM Activity log 
several messages ARC0734I ACTION=SPCMGMT are being logged and I don't want them 
displayed in the Activity log.  I remember modifying the parm in ARCCMD90 to 
supress these messages.
  

On Mon, 11/7/16, Lizette Koehler  wrote:

 Subject: Re: SUPRESSING MESSAGES - DFHSM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, November 7, 2016, 12:28 PM
 
 So what do you want to
 suppress?
 
 Is this from
 DFHSM producing the message at all?
 
 Using the MPF list to suppress the message?
 
 Using a tool like CA OPS/MVS
 or IBM Tivoli to suppress the message?
 
 I am not sure what solution you are looking  for.
 
 Did you try searching
 in www.ibm.com for how to do this?
 
 
 If you think the messages are
 too frequent, then maybe you should open an SR to IBM to see  why that is 
occurring?  Perhaps you have something running  too often.
 
 Lizette
 
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]  On  > Behalf Of esmie moo  
> Sent: Monday, November 07, 2016 9:50 AM  > To: IBM-MAIN@LISTSERV.UA.EDU  > 
Subject: SUPRESSING MESSAGES - DFHSM  >  > Gentle Readers,  >  > One of our HSM 
 STC's has been inundated with ARC0734I ACTION=SPCMGMT.  I  > remember that 
there is a SETSYS parm  in the HSM parmlib which would allow us  >  to supress 
these messages.  I cannot remember the parm  name.  Can anybody  > suggest what 
it  is?
 >
 > Thanks In
 advance.
 > 
 
 --
 For IBM-MAIN subscribe / signoff / archive  access instructions,  send email 
to lists...@listserv.ua.edu  with the message: INFO IBM-MAIN

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

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

Re: TSO Command to issue message to Outtrap

[Anthony Thompson]

TSO/e has largely been 'stabilized'. No further development, in other words, 
unless required by other software products. IBM don't spend any effort to 
upgrade old TSO commands that use TPUT/TGET (SVC 93/94) to favour 
PUTLINE/PUTGET or whatever. That is nothing new, otherwise those commands would 
have been re-written literally decades ago.

'That long to fix it', in IBM terms, means that everyone should be used to the 
behaviour of old TSO commands, and they have no intention of upgrading them for 
what are not game-changing trivialities.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, 3 November 2016 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Command to issue message to Outtrap

On 2016-11-02 20:39, Jesse 1 Robinson wrote:
> Clist has been subject to the same restrictions since long before Rexx came 
> to TSO/E. It's not up to Rexx to fix the problem.  
> 
You mean they had that long to fix it and they haven't?

But I said, "... or arrange that it be fixed ..."  If needed they should pass 
the requirement on to the department in charge.

I feel the same about ISPF's SUBMIT command's losing data.  TSO SUBMIT fails 
with a message if it can't handle the input.  ISPF simply discards enough data 
that it fits and doesn't even tell the user, much less provide an option to 
cancel.

-- gil

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

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

Re: XCFAS high CPU after z13s upgrade

[Anthony Thompson]

Do you have Health Checker running?

That has some nice checks for XCF, like storage constraints for coupling 
facilities and transport group limits.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tracy Adams
Sent: Friday, 28 October 2016 2:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCFAS high CPU after z13s upgrade

Yes all prereq maintenance was applied :-)  Yeah my next step was to open a 
problem with IBM, my hope was a dope slap with something obvious :-)  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, October 27, 2016 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCFAS high CPU after z13s upgrade

Or you may wish to contact CA Sysview support as well. Could be that they are 
reporting data different?

Did you put on all the z13 maintenance on for CA and IBM products before the 
upgrade?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Thursday, October 27, 2016 9:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XCFAS high CPU after z13s upgrade
> 
> I might be faster to open an SR/PMR with IBM XCF.  That way IBM can 
> determine if there is a bug or configuration issue for you
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tracy Adams
> > Sent: Thursday, October 27, 2016 8:27 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: XCFAS high CPU after z13s upgrade
> >
> > Hi there all,
> >
> > Pardon my lack of experience with XCF but I lived in a UNI shell for 
> > years now I am enlightened to the world of XCF.  I am wondering what 
> > could be wrong here and looking for your suggestions on where to go...
> >
> > Back ground:  we were running two 196's using escon CTC connections 
> > with a 14 year old policy using two primary structures (small and 
> > large).  One dedicated coupling facility and one LPAR.  The shop 
> > keeps all the smf data but rarely runs Monitor III so I am in the 
> > process of looking for old type 74 records to get some comparison data.
> >
> > Upgrade:  installed two z13s last weekend  with ISA links.  The VAR 
> > rewrote the CFRM policy to use six structures (1 & 2 for small, 3 &
> > 4 for medium, 5 &
> > 6 large).  The dedicated coupling facility (on the F03 box) is 
> > defined for "thin dispatch".  The VAR that installed the z13's 
> > recommended this coupling definition based on the faster ISA links 
> > and the use of thin
> dispatch.
> >
> > The net result is that lpar MVSA's address space XCFAS, running on 
> > the F03, is now consuming over the 15 minute interval 10%+ cpu 
> > utilization every interval all day long.  Using SYSVIEW and looking 
> > at the PLEXGRPS the IORt is pretty consistent in the 1000 total.
> > The CPU for MVSA's XCFAS though is very jumpy, sub 1% for a couple 
> > of whacks of the enter key, 30-50% for a couple of whacks of the 
> > enter key.  The monitor III display shows 86% of the xcf calls going 
> > through small structure 1, 13% of the xcf calls going through 
> > structure 3, and 1% going through structure 5.  There is a little 
> > that hits structure 2 but it
> is insignificant.  XCFAS on MVSC, the M03 box running the couple lpar, 
> is < 1%
> > CPU.   Prior to the upgrade XCFAS on both systems averaged < 1% for most 15
> > minute intervals and peaked at 3% maybe once or twice a day for an interval.
> >
> > The bottom line is the MVSA image does two things for us, IDMS and batch.
> > MVSC is CICS and DB2.  The IDMS/CICS relationship is the majority of 
> > the XCF usage.  Batch is getting WLM CPU delays due to high cpu from 
> > SYSTEM (xcfas) even though we added 20% more MSUs in the upgrade.
> >
> > I guess the real bottom line question though is why did my combined 
> > XCFAS cpu consumption go from an average of < 1 % on each MVS lpar 
> > to 10%+ on one and stayed the same on the other?
> >
> > Thanks in advanced for giving this post some time and energy :)
> >
> > Tracy

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

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

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

Re: EXTERNAL: Re: many OMVSKERN task not stop

[Anthony Thompson]

Just so. Check the AUTOLOG statement in the TCPIP PROFILE deck.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Wednesday, 26 October 2016 3:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: many OMVSKERN task not stop

My suspicion is you are starting your Telnet Server out of your TCPIP proccess 
with an auto start. When your Telnet server abends it gets auto started once 
TCPIP notices.


On Tue, 2016-10-25 at 18:42 +0100, Giovanni Bozzetti wrote:
> Lizette
>
> Is during normal work.
>
> Seems to me that TCPIP is restarting INETD many times, I did find a 
> message that TCPIP is in loop
>
> Seems TCPIP is not understand the port where INETD is working and try 
> to restart all the time
>
> We just see this task this month we have sure that last month they are 
> not there, can be some maintenance, we are looking
>
> Regards
> Giovanni
> System Programmer
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, October 25, 2016 05:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: many OMVSKERN task not stop
>
> I am not sure I understand.
>
> Is this during a shutdown for an IPL?
>
> A normal process where you want to shutdown OMVS?
>
> Could you provide an example or more details?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv.ua.ed 
> > U] On Behalf Of Giovanni Bozzetti
> > Sent: Tuesday, October 25, 2016 6:10 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: many OMVSKERN task not stop
> >
> > Hi
> >
> >
> >
> > We have z/OS 1.13 and z/OS 2.1  running with all last APAR but now 
> > we observe that OMVSKERN task didn't stop anymore
> >
> >
> >
> > We can find lot of this task started we can cancel but after some 
> > time it appears again.
> >
> >
> >
> > Someone know why this is happen ?
> >
> >
> >
> > Regards
> >
> > Giovanni
> >
> > System Programmer
> >
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---
> ---
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN
--
Jerry Whitteridge  

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


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

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

Re: TIME= on JOB card vs. EXEC card

[Anthony Thompson]

Assuming the JOBCLASS has specified TIME=3, then coding TIME=3 on each job step 
is wasted  and redundant effort.

With five steps, each individual step is limited to 3 minutes of CPU time, and 
the total CPU time absorbed by all steps (by the job) is similarly limited to 3 
minutes. 

So if the first step uses 2 minutes, 59 seconds of processor time, the 
remaining four steps have a grand total of 1 second of CPU time to successfully 
complete in, irrespective of what in coded on the various step's TIME parameter.

Complicating the above simplicity is the possibility of an IEFUTL exit that may 
extend the CPU time limit, based on whatever operational or business logic. The 
exit is called whenever a step of job CPU time limit is reached (and when job 
wait time as defined in SMFPRMxx is exceeded).   

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, 25 October 2016 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

Issue: we're trying to limit jobs to a particular amount of CPU time. I'm not 
sure of the relationship between JOB time and STEP time. I understand that 
TIME=3 on the STEP limits that step to 3. With 5 steps, what is the limit for 
the whole job? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, October 24, 2016 8:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TIME= on JOB card vs. EXEC card

Specifies the default for the maximum processor time that each job step may run.
And that CPU Time not clock time.

So each step no more than 3 minutes.  3 mins 1 sec it fails on that step.

So is there a specific issue you are trying to resolve?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, October 24, 2016 7:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> OK, consider this case. All defaults, no TIME= coded anywhere. JES2 
> parms have TIME=3. Five steps. How long will the job run?
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Anthony Thompson
> Sent: Monday, October 24, 2016 6:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TIME= on JOB card vs. EXEC card
> 
> As Lizette said. Default job TIME is set in the JOBCLASS definition in 
> the
> JES2 parameter deck.
> 
> If JOBCLASS doesn't specify a CPU time limit, the IBM default is 30 minutes.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, 25 October 2016 9:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TIME= on JOB card vs. EXEC card
> 
> My understanding is the step is the step - but if coded on the JOBCARD 
> it rules it all.
> 
> Also, if your JES2 JOBCLASS has a time lime, then that will control all of it.
> 
> Found that out the hard way.
> 
> So if you have a time limit on the JOBCLASS def in JES2, it takes 
> precedent If nothing major in the JOBCLAS def, but you have a STEP 
> TIME coded, then so long as the step time does not exceed the JOBCLASS 
> it will work If you have TIME coded on the JOB and it does not exceed 
> the JOBCLASS, it will work If you have TIME coded on the JOB and the 
> STEP then the JOB TIME limit will restrict the STEPs.  If the total 
> time executed for all steps exceeds the TIME= on the JOBCARD then it abends.
> 
> Good write up on KB here
> 
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2
> r2.ieab5
> 00
> /iea3b5_JOB_and_EXEC_TIME_parameter.htm
> 
> 
> By coding TIME=1440 or TIME=NOLIMIT, the TIME parameter can instead be 
> used to give a job or step an unlimited amount of time. Specifically, 
> the system allows a step to remain in a continuous wait state for an 
> unlimited time, rather than the time limit established through SMF. 
> However, if TIME=1440 is specified on the JOB statement, any TIME 
> values on an EXEC statement and any default TIME values will be 
> nullified. All steps within the job will have unlimited time, as with 
> TIME=1440 or TIME=NOLIMIT.
> 
> 
> Note: the JES2 JOBCLASS definition can m

Re: TIME= on JOB card vs. EXEC card

[Anthony Thompson]

As Lizette said. Default job TIME is set in the JOBCLASS definition in the JES2 
parameter deck.

If JOBCLASS doesn't specify a CPU time limit, the IBM default is 30 minutes. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, 25 October 2016 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TIME= on JOB card vs. EXEC card

My understanding is the step is the step - but if coded on the JOBCARD it rules 
it all.

Also, if your JES2 JOBCLASS has a time lime, then that will control all of it.

Found that out the hard way.

So if you have a time limit on the JOBCLASS def in JES2, it takes precedent If 
nothing major in the JOBCLAS def, but you have a STEP TIME coded, then so long 
as the step time does not exceed the JOBCLASS it will work If you have TIME 
coded on the JOB and it does not exceed the JOBCLASS, it will work If you have 
TIME coded on the JOB and the STEP then the JOB TIME limit will restrict the 
STEPs.  If the total time executed for all steps exceeds the TIME= on the 
JOBCARD then it abends.

Good write up on KB here

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab500
/iea3b5_JOB_and_EXEC_TIME_parameter.htm


By coding TIME=1440 or TIME=NOLIMIT, the TIME parameter can instead be used to 
give a job or step an unlimited amount of time. Specifically, the system allows 
a step to remain in a continuous wait state for an unlimited time, rather than 
the time limit established through SMF. However, if TIME=1440 is specified on 
the JOB statement, any TIME values on an EXEC statement and any default TIME 
values will be nullified. All steps within the job will have unlimited time, as 
with TIME=1440 or TIME=NOLIMIT.


Note: the JES2 JOBCLASS definition can make things interesting.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, October 24, 2016 3:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TIME= on JOB card vs. EXEC card
> 
> It's embarrassing to have to ask this question after decades in the 
> biz, but I want to confirm my understanding of the TIME parameter and 
> how it works on the JOB card vs. EXEC PGM= (step) card.
> 
> The doc is pretty clear about the step level. What you code (or accept 
> as default from JES) sets the limit for that step. When you reach that 
> limit, IEFUTL gets control. This is true for each individual step 
> regardless of other steps.
> 
> The role of TIME= on the JOB card is not so clear, especially in 
> relation to a default. As I read the doc, there is no specific default 
> for JOB time parameter. That is, the effective limit for the whole JOB 
> is the sum of all the individual steps. If you don't want the job to 
> run that long, you can code TIME= for some lower value. But you cannot 
> increase the JOB time by coding a higher value. And if don't code it at all, 
> you get the sum of the steps.
> 
> From the JCL manual:
> 
> "You can use the TIME parameter on a JOB statement to decrease the 
> amount of processor time available to a job or job step below the 
> default value. You cannot use the TIME parameter on a JOB statement to 
> increase the amount of time available to a job step over the default 
> value. To increase the allowable time over the default value, use the TIME 
> parameter on the EXEC statement."
> 
> In other words, there is no explicit default value at the job level. 
> Am I right?
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com

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

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

Re: Capture REXX/CLIST software usage.

[Anthony Thompson]

SMF parm for CLISTS? Lizette, I think your referring to SMF type 32 (TSO 
command usage), turned on by specifying DETAIL for SUBSYS(TSO) in SMFPRMxx. 

I don't think that helps Massimo, given that it requires code within the 
command in order to be registered in SMF 32's (an SVC 109 function) and doesn't 
work for TSO batch.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 15 September 2016 10:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Capture REXX/CLIST software usage.

If the REXX/CLIST is a member in a dataset, then SMF Type 42 records may be 
helpful.  It can track in a subtype the use of a member.  It will depend on 
your level of z/OS.

If it is instream, then I think harder to do.

There was or is an SMF Parm for CLISTs I think.  It has been  some time since I 
looked at that.

Do you have tools like:  SAS/MXG, SAS/MICS, Tivoli, etc.?  Otherwise I think 
DFSORT ICETOOLS can use the SMF Type 42 and break it down.

Other option is to install DAF from cbttape.org.  You can tailor that to what 
you need for SMF reporting.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Massimo Biancucci
> Sent: Thursday, September 15, 2016 3:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Capture REXX/CLIST software usage.
> 
> My main goal is to find out who uses what.
> 
> If I will success after a while I'll have a view of what REXX/CLIST 
> are still in use.
> 
> I'm working on systems who were build ages ago and dealing with 
> different thousands of exec on tenth of libraries.
> 
> The VLF maybe a parallel way even though I've to discuss with customer 
> in order to evaluate pro (a lot) and cons.
> 
> I know that the more I monitor the worst I get, anyway we use TADz to 
> delete old applications and we'd like to do the same for system pgmr stuffs.
> 
> Thanks again to everybody.
> Massimo
> 
> 2016-09-15 3:04 GMT+02:00 Anthony Thompson <anthony.thomp...@nt.gov.au>:
> 
> > Maybe you can add your REXX/CLIST libraries to VLF and use SMF type 
> > 41 records to see which ones are being called.
> >
> > Ant.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Massimo Biancucci
> > Sent: Wednesday, 14 September 2016 7:35 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Capture REXX/CLIST software usage.
> >
> > Hi everybody,
> >
> > I'm wondering what's (if it's reasonable) the best way to capture 
> > usage of REXX/CLIST member.
> >
> > For LOAD member it's possible to "monitor" some SVC and capture the 
> > information (like TADz).
> >
> > I've tried to run a simple JCL:
> >
> > //ST003EXEC  PGM=IKJEFT01
> > //SYSPROC  DD DSN=myexec,DISP=SHR
> > //SYSTSPRT DD SYSOUT=*
> > //SYSPRINT DD SYSOUT=*
> > //SYSTSIN  DD *
> >  %TEST
> > /*
> >
> > and capture with a GTF all the SVCs called.
> >
> > I'm expecting at least a BLDL but nothing.
> >
> > The goal is to know what piece of software are used and, in a 
> > statistic way, clean the libraries from unused software,
> >
> > Any idea ?
> >
> > Thanks a lot for your support.
> > Massimo

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

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

Re: Capture REXX/CLIST software usage.

[Anthony Thompson]

Maybe you can add your REXX/CLIST libraries to VLF and use SMF type 41 records 
to see which ones are being called.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Massimo Biancucci
Sent: Wednesday, 14 September 2016 7:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Capture REXX/CLIST software usage.

Hi everybody,

I'm wondering what's (if it's reasonable) the best way to capture usage of 
REXX/CLIST member.

For LOAD member it's possible to "monitor" some SVC and capture the information 
(like TADz).

I've tried to run a simple JCL:

//ST003EXEC  PGM=IKJEFT01
//SYSPROC  DD DSN=myexec,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD *
 %TEST
/*

and capture with a GTF all the SVCs called.

I'm expecting at least a BLDL but nothing.

The goal is to know what piece of software are used and, in a statistic way, 
clean the libraries from unused software,

Any idea ?

Thanks a lot for your support.
Massimo

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

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

Re: Elementary dataset alias question

[Anthony Thompson]

You can look forward to being neither surprised nor delighted.

From Managing Catalogs, SC23-6853-02, page 19: 

"The symbolic string must not exceed 44 characters, including all name segments 
and periods."


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, 31 August 2016 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Elementary dataset alias question

Does that restrict the length of related DSNs to 39 characters rather than 44 
because a 5-character name is replaced by a 0-character value?  Of course a 
thoughtful design would allow the SYMBOLICRELATEd DSN to be comfortably longer 
then 44 characters because symbol resolution may reduce that length.
Somehow I don't trust IBM designers to have been so thoughtful.  For example, 
ISPF DSLIST restricts the name entered to be at most 44 characters regardless.
I'd be delighted to be surprised.

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

Re: OPERLOG vs SYSLOG

[Anthony Thompson]

More significant for us was the ability to look at any system's log via SDSF 
from any other system in the 'plex (we're not MASPOOL). Also the ability to 
diagnose IPL errors from another system by being able to scroll through and 
eyeball the problem system's IPL messages prior to its JES initializing.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Zahir Hemini
Sent: Friday, 19 August 2016 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OPERLOG vs SYSLOG

We found that we preferred the direct access to Operlog data for report and 
analytical programs, to the two step process you have suggested. After the 
Operlog was set up and identified we never had any inclination to go back to 
Syslog.


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

Re: Inappropriate posts

[Anthony Thompson]

https://www.youtube.com/watch?v=sffSw-et9UM



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Saturday, 16 July 2016 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inappropriate posts

Tom Brennan wrote:

>https://www.youtube.com/watch?v=DKtjBqJ4NxA

>What a HAPPY DAY!
> From probably my favorite movie of all time.

Hahaha. A good video. Thanks Tom.

Groete / Greetings
Elardus Engelbrecht

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

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

Re: Already logged on message - Wrong System ID

[Anthony Thompson]

Don't really understand that JCL. What is the point of IEBGENER stuff there?

Isn't the only DD-card of relevance the /*$VS 'CANCEL ' ? Wouldn't 
IEFBR14 do just as well?

Why not the more modern // COMMAND syntax, avoiding the cumbersome $VS crap 
(and use C U= rather than the bigger hammer CANCEL?). Always assuming 
the appropriate authorities are allowed via RACF OPERCMDS and the JES command 
authorities defined for that job class.

And how does the OP get to edit/submit that job when he can't log in on another 
LPAR?

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Friday, 15 July 2016 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Already logged on message - Wrong System ID

Here it is again, but now with quotes around the JCL ... 

Update and submit the following JCL, but from a different LPAR and on which you 
can logon:

'/*ROUTE XEQ '
'//*'
'//*'
'//* ISSUE MVS COMMANDS IN BATCH   *'
'//*   *'
'//*'
'//*'
'//INTRDR  EXEC PGM=IEBGENER
'
'//SYSPRINT  DD SYSOUT=*
' 
'//SYSIN DD DUMMY   
'  
'//SYSUT2DD SYSOUT=(*,INTRDR)   
' 
'//SYSUT1DD *,DLM=@@
'   
' '/*$VS,'CANCEL   
' 
'@@ 
'   
'//*'
'// 
'  

This should terminate your being logged on the other named LPAR (e.g. 
LPAR1 or LPAR2) within the sysplex.

CP (retired sysprog)


Tom Marchant wrote:

>On Thu, 14 Jul 2016 17:08:28 +0530, Jake Anderson wrote:
>
>  
>
>>I am trying to access one of an LPAR1 within a sysplex. Where I get a 
>>message as you already logged on to LPAR1. When I have someone to 
>>check my ID from other system its shows that My ID is active in LPAR2.
>>
>>
>
>We cannot help you to understand what is happening when you paraphrase the 
>messages that you receive. Please give the exact messages. Include the 
>response from D TS,L on both LPARs.
>
>  
>
>>We have MIM but we have not enabled Parallel Logon facility serialization.
>>
>>I am curious why z/OS is displaying a wrong System Name instead of the 
>>One my ID is active ?
>>
>>
>
>I am curious why you think that the system is giving you the wrong 
>information, rather than that you are not connecting to the system that you 
>want.
>
>  
>
>>Its like I am logged into LPAR2, but when I try accessing LPAR1, it 
>>shows that you are already logged on to LPAR1..
>>
>>
>
>Does it really say LPAR1? Or does the it just say that you are already logged 
>on the the current LPAR?
>
>  
>
>>This gets resolved after My ID is cancelled from LPAR 2.
>>
>>
>
>If your session was really cancelled on LPAR2, you were logged on to 
>LPAR2, not LPAR1
>
>  
>

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

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

Re: Character data returned from

[Anthony Thompson]

Use the  function. 

SET ASTER=(*)   

GETFILE INPUT
SET PLACE = (,)   
IF =0 THEN -   
  GOTO PROCESS 
ELSE -  
  GOTO REJECT

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Reichman
Sent: Thursday, 7 July 2016 7:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Character data returned from 

I am scanning input cards which all have characters A - Z there is one card 
with a * that causes the problem

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, July 6, 2016 5:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Character data returned from 

And if that does not work, then show the code you are using.

Include how you set the variable,
What the variable contains,
And what you are using for ( )

CONLIST, SYMLIST, LIST is helpful.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, July 06, 2016 2:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Character data returned from 
> 
> So you may also want to join, if you have not done so, the TSO REXX 
> list.  We speak CLIST There.
> TSO REXX  http://www2.marist.edu/htbin/wlvindex?TSO-REXX
> Go to bottom of webpage to join
> 
> 
> Try using 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman
> > Sent: Wednesday, July 06, 2016 12:49 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Character data returned from 
> >
> > Hi
> >
> > Is there anyway to check that  converted the variable in 
> > question to valid characters
> >
> > After the  if do a compare in which case the variable had an '*'
> > and I am getting "expression with operators out of sequence
> >
> 

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

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

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

Re: Soft Capping

[Anthony Thompson]

CVT + x'25C' = address of RMCT (SRM control table)
RMCT + x'E4' = address of RCT (SRM resource control table)
RCT + x'C4' = RCTLACS (4 bytes, unsigned, long-term no. Of MSU's consumed by 
LPAR) 
RCT + x'1C' = RCTIMGW (4 bytes, unsigned, no. of MSU's available to LPAR)

If RCTLACS > RCTIMGWU, the LPAR is soft-capped (if they're equal, may be 
hard-capped, may be soft-capped, might just be busy).

SYSEVENT REQLPDAT returns the same information in fields LPDATAVGIMGSERVICE and 
LPDATIMGCAPACITY, as I think you've figured out. 

Ant.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Austin
Sent: Wednesday, 29 June 2016 10:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Soft Capping

Is there a way to determine programmatically if soft capping is being applied 
to a z/OS image?

Thanks



--
This e-mail message has been scanned and cleared by Google Message Security and 
the UNICOM Global security systems. This message is for the named person's use 
only. If you receive this message in error, please delete it and notify the 
sender. 

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

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

Re: Netstat (EZANS) for z/OS 2.2

[Anthony Thompson]

It's not at all difficult to keep it working. Update the initialization section 
of the EZANS REXX from around line 180-ish on. I don't think there have been 
any changes to the netstat command syntax since z/OS 1.13.

Ant. 

/**/
/**/
/* Determine release of this z/OS system and initialize our   */
/* release identifier variable: z/OS VnRn */
/**/
/* Also initialize a numeric representation of this release to be */
/* used when determining which functions are available at which   */
/* releases.  Format of this is 'oovvrr' - oo is 01 for z/OS, vv is   */
/* 2-digit version, and rr is 2-digit release.  z/OS V1R4: '010104'   */
/**/
/**/

address ISPEXEC "VGET (ZOS390RL ZSYSID) ASIS"   
parse var ZOS390RL EZANSOS " " EZANSOSV "." EZANSOSR "." EZANSOSM . 
EZANSOSV = right(EZANSOSV,2)
if ezatracei then do
   say h||'ZOS390RL='ZOS390RL   
   say h||'OS='EZANSOS  
   say h||'VV='EZANSOSV 
   say h||'RR='EZANSOSR 
   say h||'MM='EZANSOSM  
end 

EZANSOSV = right(EZANSOSV,1)
If EZANSOSR < '10' then 
   EZANSOSR = right(EZANSOSR,1) 
EZANSREL = EZANSOS||" V"||EZANSOSV||'R'||EZANSOSR   

if ezatracei then say h||'EZANSREL='EZANSREL
EZANSHDT = EZANSREL||' CS TCP/IP NETSTAT'   

if ezatracei then say h||'EZANSHDT='EZANSHDT

zosv1r4 = '010104'  
zosv1r5 = '010105'  
zosv1r6 = '010106'  
zosv1r7 = '010107'  
zosv1r8 = '010108'  
zosv1r9 = '010109'  
zosv1r10 = '010110' 
zosv1r11 = '010111' 
zosv1r12 = '010112' 
zosv1r13 = '010113' 
zosv2r1  = '010201' /* Ant1 */  
zosv2r2  = '010202' /* Ant2 */  

thisrel = zosv1r4   

if EZANSREL = 'z/OS V1R4' then  
   thisrel = zosv1r4
if EZANSREL = 'z/OS V1R5' then  
   thisrel = zosv1r5
if EZANSREL = 'z/OS V1R6' then  
   thisrel = zosv1r6
if EZANSREL = 'z/OS V1R7' then  
   thisrel = zosv1r7
if EZANSREL = 'z/OS V1R8' then  
   thisrel = zosv1r8
if EZANSREL = 'z/OS V1R9' then   
   thisrel = zosv1r9 
if EZANSREL = 'z/OS V1R10' then  
   thisrel = zosv1r10
if EZANSREL = 'z/OS V1R11' then  
   thisrel = zosv1r11
if EZANSREL = 'z/OS V1R12' then  
   thisrel = zosv1r12
if EZANSREL = 'z/OS V1R13' then  
   thisrel = zosv1r13
if EZANSREL = 'z/OS V2R1'  then /* Ant1 */   
   thisrel = zosv2r1/* Ant1 */   
if EZANSREL = 'z/OS V2R2'  then /* Ant2 */   
   thisrel = zosv2r2/* Ant2 */   
 
EZANSCRL = thisrel   
address ISPEXEC "VPUT (EZANSCRL) SHARED" 
 
If ezatracei then say h||'Thisrel='thisrel   


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, 29 June 2016 1:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Netstat (EZANS) for z/OS 2.2

My last conversations with IBM on this is - not supported.  It was a tool 
developed by an IBMer that retired and the Communication Server Team preferred 
not to 

Re: Getting timely dump out of LE

[Anthony Thompson]

I was wondering if you looked in LOGREC to see if that recorded the first S0C4.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Wednesday, 25 May 2016 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I wouldn't think that more than one of the 0C4's in the system trace would 
match the PSW in the MCH control block. You can display time in the system 
trace by doing 'ip systrace time(local)'. For the wrapping issue... some 
version of z/OS allowed the system trace table size to be set much higher. I 
recently asked our guys to bump up to 12M and that seems to be working for now.

In article <2013103444541247.wa.ronmacraehotmail.co...@listserv.ua.edu> you 
wrote:
> Lizette,
>I can get the registers and PSW no problem.  The problem I have is 
> getting the TIME of the S0C4 so I can see which one is first.  So much 
> happens before LE gets round to taking a system dump that the z/OS trace has 
> wrapped and I can't tell which of the 6 S0C4 abends, on different TCBs, was 
> first. I don't think I can assume that the first to produce a CEE dump or the 
> first to produce a SYSMDUMP was the first as they seem to preempt each other.

> Anyway I got round the problem by slipping on the instruction that sets us up 
> to fail by setting a control block pointer to zero before any of the TCBs 
> S0C4ed.

> However it would have been nice to be able to tell the time of the S0C4s.

> Ron.

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

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

Re: AXR04 System REXX

[Anthony Thompson]

z/OS 2.2 introduces some overdue commands/controls to manage system REXX 
address spaces.

There is finally a stop command: P AXR

There are a number of new modify commands, like F AXR,SR,STOPTSO to stop all 
TSO server address spaces, or F AXR,SR,CANCEL,REQTOKEN= to cancel a 
given system REXX address space. See z/OS 2.2 System Commands.

There are also a couple of new AXR PARMLIB member options to set the time-out 
limit and maximum number of address spaces.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Wednesday, 27 April 2016 11:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AXR04 System REXX

The last time I looked at bringing down AXR it was:  FORCE AXR,ARM

Is anyone aware of another method or does this still hold true?

Bob

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

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

Re: New to RACF

[Anthony Thompson]

Thanks for pointing out %08X (pad 8-character field with zeroes to exceed 
default precision). I'm not that big on C/C++ as yet, still learning. So are 
IBM z/UNIX programmers, apparently. 

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, 22 April 2016 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

Or they could use "%08X" to tell printf to tag on the leading zeros - no 
counting needed.

Here's one that always looks strange to me:

"You have 1 records"

I think that *does* take some extra C coding to fix unless someone can tell me 
some printf tricks.

Years ago I wrote some assembler macros and subroutines to simulate C string 
routines, including printf.  I seem to remember having logic that would scan 
the next word in the source string looking for a trailing S, and would drop it 
if the number displayed was 1.  For example:

   #PRINTF 'You have %d records',COUNT

... would result in good grammar no matter what number was displayed.

Anthony Thompson wrote:
> The error reason is actually 0B7F1C00, it's the C/C++ library functions being 
> called from within copytree command (like printf, fprint, etc) that drop 
> leading zeroes. I've seen it many times in error messages from z/UNIX 
> commands . It is fixable in C/C++ code, but the programmer needs to count the 
> number of digits to be output and manually add their own leading zeros. Not 
> many can be bothered.

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

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

Re: New to RACF

[Anthony Thompson]

The error reason is actually 0B7F1C00, it's the C/C++ library functions being 
called from within copytree command (like printf, fprint, etc) that drop 
leading zeroes. I've seen it many times in error messages from z/UNIX commands 
. It is fixable in C/C++ code, but the programmer needs to count the number of 
digits to be output and manually add their own leading zeros. Not many can be 
bothered.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, 22 April 2016 2:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New to RACF

On 21 April 2016 at 12:01, Tracy Adams  wrote:
> seteuid 0
> Error codes: 0 -1 A4 B7F1C00
> EMVSSAF2ERR: SAF/RACF error
>
> Dubious nothing has changed in the RACF world and this use to work.  The only 
> thing I can find is that the userid needs acc(read) to bpx.superuser which it 
> does.  Where do I begin to debug this RACF error?

Are you sure the line with the error codes was copied accurately? I would 
expect the last piece to have 8 hex digits; it's the errno2 value. The A4 
(EMVSSAF2ERR) is saying it's a RACF error encountered by the UNIX seteuid() 
service. The last two bytes (4 digits) of that 8 character hex string should be 
the RACF return and reason codes from the RACF IRRSEU00 callable service, 
described in the RACF Callable Services book.

If it's really coming out as 7 digits, then I'd call IBM and complain.
If it got mangled or typo'd, then look up the corrected version in the Callable 
Services book and see if that leads you further. All this seems to have to do 
with authorization to change the effective UID.

Tony H.

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

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

Re: DAF on z/OS V2?

[Anthony Thompson]

I've both assembled and run it ox z/OS 2.2, but then again I turned off most of 
the customizable switches.

   SETC 'YES' Check DSN (YES/NO)   
  SETC '025' Message Limit (nnn/000)  
 SETC '025' SNAP Limit (nnn/000) 
 SETC 'NO ' Trace (YES/NO)   
   SETC 'DAFTRACE' Trace DDNAME (DDNAME)   
  SETC '000' Permanent read errors (nnn/000)  
  SETC '000' Permanent write errors (nnn/000) 
  SETC '000' Temporary read errors (nnn/000)  
 SETC '000' Temporary read backward errors (nnn/000) 
 SETC '000' Temporary read forward errors (nnn/000)  
  SETC '000' Temporary write errors (nnn/000) 
 SETC '000' Temporary write errors (nnn/000) 
_AO  SETC '000' AO (nnn/000) 
_BATCHPIPES  SETC '000' BatchPipes (nnn/000) 
_BDT SETC '000' BDT (nnn/000)
_DFPACS  SETC '000' DFP ACS (nnn/000)
_DFSMS   SETC '000' DFSMS (nnn/000)  
_DFSORT  SETC '000' DFSORT (nnn/000) 
_DIV SETC '000' DIV (nnn/000)
_ESV SETC '000' Error Statistics By Volume (nnn/000) 
_HSMFSR  SETC '000' HSM FSR (nnn/000)
_ICSFSETC '000' ICSF (nnn/000)   
_NFTPSETC '000' NFTP (nnn/000)   
_RACFSETC 'YES' RACF (YES/NO)
_RMDSSETC '000' RMDS (nnn/000)   
_RMF SETC 'NO'  RMF (YES/NO)
_RMMAUD  SETC '000' RMM Audit (nnn/000) 
_RMMSEC  SETC '000' RMM Security (nnn/000)  
_TCPIP   SETC '118' TCPIP (nnn/000) 
_TCPIPX  SETC '119' TCPIPX (nnn/000) new in 
_USS SETC '000' USS (nnn/000)   
_VSAMCAT SETC 'NO'  VSAM Catalog (YES/NO)   
_VSR SETC '000' Virtual SMF (nnn/000)   
_DFSMS03 SETC 'NO'  DFSMS ST 03 (YES/NO)  
_DFSMS06 SETC 'NO'  DFSMS ST 06 (YES/NO)  
_DFSMS07 SETC 'NO'  DFSMS ST 07 (YES/NO)
_DFSMS09 SETC 'NO'  DFSMS ST 09 (YES/NO)   
_DFSMS10 SETC 'NO'  DFSMS ST 10 (YES/NO) 
_DFSMS16 SETC 'NO'  DFSMS ST 16 (YES/NO)
_DFSMS20 SETC 'NO'  DFSMS ST 20 (YES/NO) 
_DFSMS21 SETC 'NO'  DFSMS ST 21 (YES/NO)  
_DFSMS24 SETC 'NO'  DFSMS ST 24 (YES/NO) 
_DFSMS25 SETC 'NO'  DFSMS ST 25 (YES/NO) 
_DFSMS22 SETC 'NO'  DFSMS ST 22 (YES/NO)   
_DFSMS23 SETC 'NO'  DFSMS ST 23 (YES/NO)   
_FTPAPPE SETC '070' FTP Server Append ST (nnn/000)  
_FTPCLIENT   SETC '003' FTP Client ST (nnn/000) 
_FTPCOMMON   SETC '000' FTP Server Common ST (nnn/000)  
_FTPDEL  SETC '071' FTP Server Delete ST (nnn/000)  
_FTPLOGN SETC '072' FTP Server Logon Failed ST (nnn/000)
_FTPREN  SETC '073' FTP Server Rename ST (nnn/000)  
_FTPRETR SETC '074' FTP Server Retrieve ST (nnn/000)
_FTPSTOR SETC '075' FTP Server Store ST (nnn/000)   
_RMMAUD  SETC '000' RMM Audit (nnn/000) 
_RMMSEC  SETC '000' RMM Security (nnn/000)   

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, 20 April 2016 2:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DAF on z/OS V2?

Is anyone successfully running Michael Cleary's DAF (Dataset Audit Facility) on 
z/OS V2?   I've seen him on IBM-Main occasionally, but I cannot even 
successfully assemble it on z/OS V2.2.   According to his webpage, last updates 
were in 2010.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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

Re: Setting up z/OSMF under 2.1

[Anthony Thompson]

Obviously, they don't, since they are unique ISPF profile datasets.

With z/OSMF, it's much like TSO. You are prompted for the TSO logon proc you 
want to use (with all the consequent allocations, either explicit or via a 
CLIST/REXX invoked from the logon proc).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, 19 April 2016 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Setting up z/OSMF under 2.1

On 2016-04-18, at 17:34, Jesse 1 Robinson wrote:

> Update. I now have the z/OSMF server up and running with PARMLIB member 
> IZUPRMxx. Have not tried any plugins except ISPF, which works well so far. An 
> interesting wrinkle with ISPF. I you want to use it from z/OSMF at the same 
> time you're logged in via TSO, you have to include an option I did not even 
> know about: 
> 
> ISPF/PDF SHRPROF
> 
>  We've had multi-system ISPF support for years by allocating a unique 
> ISPPROF dataset on each sharing system. 
>  
Then how do profile changes made on one system get propagated to those other 
systems?  Years ago, our systems programmer accommodated by configuring MIM not 
to propagate the ISPPROF ENQ.

-- gil

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

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

Re: How to make USS ROOT read/write temporarily?

[Anthony Thompson]

I use the chmount command:

chmount -w /  (and the -r switch is used to turn the filesystem hosting the 
named directory back to read-only)

By default this command is stored in usr/sbin, some sites moves it to /bin so 
it's in the default path.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, 13 April 2016 8:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to make USS ROOT read/write temporarily?

We need to make a production USS ROOT R/W temporarily in order to define a new 
directory that will point to a separate ZFS. Then back to read-only. I don't 
remember how to do it. Help.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


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

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

Re: Check for dynamic HCD activation

[Anthony Thompson]

I must still refer you to the 'D IOS,CONFIG' command, if you have the authority 
(in a REXX, use the SDSF ISFSLASH service).

The command response gives you the date/time of the latest I/O configuration.  
If the date/time is later than the IPL time/date, then you know there been an 
IODF activated since. The command response also tells you which IODF was 
activated, so you can interrogate the catalogue and discover which volume that 
IODF is on. If you need the unit address of that volume, look at the response 
from system command 'D U,VOL=vv'

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Friday, 4 March 2016 1:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Check for dynamic HCD activation

Thanks to those that replied.  We collect the LOAD PARM information so and 
update a chart for our operations staff based on the last IPL. This way if the 
hardware unit does an update what I called the HCD or IODF dynamically and do 
an activate we capture it, this way if it doesn’t match we automate an email to 
our staff. This way we check our LOADxx member matches the volume where the 
IODFxx is on DASD.

The goal:  We know it from yes (Mark's rexx exec, agree it's very useful)  the 
current one but if it's changed dynamically the code doesn’t pick it up, is 
there a way to pick it up through another exec or anything else? And yes we 
control dynamic activations via RACF and yes only hardware staff can do it.

-- SNIP ---



2. D IOS,CONFIG shows current configuration (IODF name) for both HSA and MVS, 
but it doesn't show whether the config was activated after IPL.
Even case where IODF HSA <> IODF MVS does not mean there was an activate, 
because system could be IPLed with non-matching IODF (which in turn disallow 
dynamic changes).

3. AFAIK Mark's IPLINFO (great tool BTW, thank you Mark!) does not show whether 
dynamic change took place.



BTW: What's the goal? IMHO there are some other methods to get such 
information. Not to mention dynamic activate should be strictly controlled and 
performed only by persons who really know what they do.

Regards
--
Radoslaw Skorupka
Lodz, Poland




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

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

Re: Check for dynamic HCD activation

[Anthony Thompson]

I'm  supposing that when you say HCD you mean IODF.

Further, when you mention REXX code, I'm guessing you are referring to Mark 
Zelden's IPLINFO REXX. 

This interrogates a couple of control blocks that I can't see documented, not 
in the Data Areas manuals, nor in MACLIB/MODGEN (IOVT and CDA ). 

I'd try to verify your assertion that these control blocks aren't updated by an 
ACTIVATE, but my company is in the throes of a mainframe upgrade and the 
sandbox sysplex is currently unavailable.

If your REXX runs under a userid with the authority to issue system commands, 
I'm wondering if you can trap the output from a 'D IOS,CONFIG' command and 
analyse the results from that.

Mr. Zelden may have more to say..


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, 3 March 2016 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Check for dynamic HCD activation

Does anyone have Rexx code to check to see if an HCD is activated dynamically 
between IPLS. My issue is I can get the IPL Load Parms when the system is 
ipl'ed by using rexx code I have gotten off of websites. What I can't detect is 
when the HCD changes between IPLS because it seems the CVT area I'm checking 
doesn’t get updated.

Thanks


Andy



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

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

Re: Outsourcing Stories Good or Bad!

[Anthony Thompson]

And saving costs is just what the OP's managers are seeking to do by 
outsourcing.

Of course, outsourcers will always present their case in the best financial 
light to gather business, and their business is to make a profit. In my 
experience the savings they advertise are rarely achieved (I've worked on both 
sides of the fence).

The outsourcers generally provide a maintenance contract, typically taking over 
the hardware, operators and system programming staff. Under that contract, 
anything outside normal maintenance of the system(s) is chargeable. Want extra 
functionality coded in an exit? Pay for it. Want an unscheduled IPL to enable 
that exit? Pay for it. Want that exit debugged? Pay for it. Just want a dataset 
temporarily APF-authorised to evaluate a product? Pay for it.

War Story 1: I was working at a certain Australian Federal Government 
department who had outsourced to a certain mob with an Australian presence 
(whom I won't name except to say they like to be known as a large colour). I 
was helping test an upgrade to z/OS. I saw that a couple of exits had been 
back-levelled, and there were a number of inconsistencies in PARMLIB. I 
realized that they had taken a copy of the production system to apply the next 
z/OS to, and had not bothered to refresh it with any of the production changes 
since. Lazy, unprofessional, or n00b stuff. Most of the errors were fixed 
immediately, but I kept complaining in our monthly meetings that they had left 
APF-authorized a few redundant, deleted datasets. When I gladly left some 
months later, those dead APF entries were still there. I believe it was simply 
because they couldn't justify charging us for that change, and there were too 
many hoops to jump through on their side to delete those APF entries without an 
associated cost code or something, so it never happened. 

War Story 2: Same place, same outsourcer.  A z/VM system was being implemented 
to host file/print servers (we had not had a z/VM environment previously). When 
I was looking at the supplied RACF database, I saw a whole mess of userids and 
profiles that simply didn't belong. They had taken some-one else's z/VM RACF 
database (I know it belonged to a particular New Zealand-based bank) and dumped 
on our system instead of providing a pristine environment. Job done. I ripped 
into them, told them (and my management) they had just given us a security 
system that allowed unauthorised people to log in with operations and systems 
programming access levels. In the end I had to go through the database and 
provide the outsourcer with a list of exactly which userids/profiles to lose.

At the risk of repeating what others have said, your management needs to put 
together a solid contract with all costs clearly spelt out, ideally with 
defined service level agreements/objectives and penalties if such aren't met 
(e.g. if Mr. Outsourcer hasn't made that PARMLIB change to delete 
APF-authorized libraries yet, we'll start charging you!). I think it would be a 
good idea to keep at least one person with solid skills to liaise with them at 
a technical level and to keep an eye on what they do, since my experience is 
that you can't necessarily trust them to do a complete or professional job, no 
matter what their reputation.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of baby eklavya
Sent: Sunday, 28 February 2016 4:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

*"The saddest part was the manager was not even literate on zOS systems.
All he knew was to save cost. So slowly most of the wannabe system programmer 
left. Now he wants a 2 year experienced guys to run equal to his
peer."*
This is exactly what i was trying to convey . At the end , they never save 
anything . Whatever money they think they had saved by replacing experienced 
staffs with freshers goes out again in the form of penalty , missed SLA , 
change failures .

Skill shortage is just one side of the story . When the work environment is 
controlled by such managers who only focus on saving cost , life becomes too 
difficult for beginners who want to learn and enhance their skills .
They eventually lose their interest in the technology  .

I remember a recent quote from Forbes.com -   "People don't leave the
companies , they leave their managers"



On Sun, Feb 28, 2016 at 11:08 AM, Jake Anderson 
wrote:

> Hi
>
> Looking at this discussion I really wanted to share something over 
> here which was shared by one of my colleague.
>
> One of an American ISV company off shored their work to India.
>
> The technicians in India wanted to get trained in many areas like zVM 
> but the Indian manager was too hesitant and said there should be lot 
> of tickets or incidents so that he can get a training. The saddest 
> part was the manager was not even literate on zOS systems. All he knew was to 
> save cost.
> So 

Re: CBPDO Order Install

[Anthony Thompson]

Did you bother to look up the explanation for your GIM45800S error message? 

GIM45800SPACKAGE package WAS NOT FOUND IN THE SMPNTS.  
 Explanation:  
 SMP/E could not locate the requested package in the SMPNTS
 directory. The package is expected in the /smpnts/package-id/ 
 directory; where "smpnts" is the directory specified for the  
 SMPNTS ddname, and "package-id" is the value specified on the 
 FROMNTS operand of the RECEIVE command.   

It really should be quite obvious how to fix this. I'm pretty sure my cat could.

1) Create a directory with the name OSP53812 in /u/ibmdownload/cobol5.2 

2) Copy everything in /u/ibmdownload/cobol5.2 to the new OSP53812 directory, 
including sub-directories.

3) Try your job again, specifying path /u/ibmdownload/cobol5.2 in your SMPNTS 
DD-card.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Friday, 19 February 2016 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CBPDO Order Install

Hello,
  I did the same as suggested in previous email but


//SMPCSI   DD  DISP=SHR,DSN=SMPE.ZOS.GLOBAL.CSI  <=== NOTE 1
//SMPNTS   DD  PATHDISP=KEEP,
// PATH='/u/ibmdownload/cobol5.2/SMPPTFIN/'
//SMPOUT   DD  SYSOUT=*
//SMPRPT   DD  SYSOUT=*
//SMPLIST  DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//**
//* AS SHIPPED BY IBM, RCVPDO IS SET UP TO RECEIVE
//* THE FMIDS, PTFS AND HOLDDATA
//**
//SMPCNTL  DD  *
  SET  BOUNDARY (GLOBAL) .
  RECEIVE
   FROMNTS(OSP53812)/* <=== NOTE 3 */
  /*DELETEPKG  /* <=== NOTE 4 */
  .
/*


JCL output

 RECEIVE
   FROMNTS(OSP53812)/* <=== NOTE 3 */
  /*DELETEPKG  /* <=== NOTE 4 */
  .

GIM45800S ** PACKAGE OSP53812 WAS NOT FOUND IN THE SMPNTS.
GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.


GIM20502ISMP/E PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
SMP/E
 IS AT LEVEL 36.68.




Under /u/ibmdownload/cobol5.2/ directory, I have

GIMPAF.XML
GIMPAF.XSL
SMPHOLD
SMPPTFIN
SMPRELF
S0001.CSP.CSP.README
S0002.CSP.OSP53812.DOCLIB.pax.Z
S0003.CSP.OSP53812.RIMLIB.pax.Z
S0005.CSP.OSP53812.PGMDIR.pax.Z
S0029.CSP.OSP53812.GIMUNZIP

and then

Under /u/ibmdownload/cobol5.2/SMPPTFIN/  directory, I have

S0006.CBCACHE.HADB520.SMPMCS.pax.Z
S0007.CBCACHE.JADB52H.SMPMCS.pax.Z
S0008.CBCACHE.JADB521.SMPMCS.pax.Z
S0009.CBCACHE.HADB520.PTF.UI27877.pax.Z
S0010.CBCACHE.HADB520.PTF.UI29671.pax.Z
S0011.CBCACHE.HADB520.PTF.UI31476.pax.Z
S0012.CBCACHE.HADB520.PTF.UI32522.pax.Z
S0013.CBCACHE.HADB520.PTF.UI33431.pax.Z
S0014.CBCACHE.HADB520.PTF.UI34228.pax.Z
S0015.CBCACHE.JADB52H.PTF.UI29672.pax.Z
S0016.CBCACHE.JADB521.PTF.UI27878.pax.Z
S0017.CBCACHE.JADB521.PTF.UI29673.pax.Z
S0018.CBCACHE.JADB521.PTF.UI31477.pax.Z
S0019.CBCACHE.JADB521.PTF.UI32524.pax.Z
S0020.CBCACHE.JADB521.PTF.UI33432.pax.Z
S0021.CSP.OSP53812.ASSIGNS.pax.Z
S0022.CSP.OSP53812.PRODDATA.pax.Z




On Thu, Feb 18, 2016 at 9:20 PM, Tom Marchant < 
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 18 Feb 2016 20:47:48 +0530, Mainframe Mainframe wrote:
>
> >I have checked MEMOTXT doc and program directory and 
> >DOCLIB,RIMLIB,PGMDIR  dataset as well shipped with this order. But 
> >Only sample JCL provided for RECEIVE FROMNTS
>
> That should give you the information that you need.
>
> >but  we downloaded with order on HFS file system
>
> Yes, that is where RECEIVE FROMNTS needs it to be.
>
> >not setup  SMPNTS,
>
> What do you mean? SMPNTS is the DD statement that points to the HFS 
> directory containing the network package. There is no setup to do for 
> it.
>
> >So, that sample JCL and control card is not useful in our case.
>
> Why not?
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Odd behaviour with DFHSM & DFSORT in batch.

[Anthony Thompson]

He did code WAIT.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Friday, 12 February 2016 3:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd behaviour with DFHSM & DFSORT in batch.

I think what is happening is that the HSEND command is done asynchronously and 
therefor the dataset has not been created when the dfsort step runs.

You might code wait and that should help.

Ed

On Feb 11, 2016, at 9:06 AM, Vince Getgood wrote:

> Hi all,
> I've discovered some very odd behaviour when running a DFHSM command 
> in the same batch job as a DFSORT step, and I'm completely baffled by 
> what's happening.
>
> We're running z/OS 2.2, although it also happens on 1.3 and 1.10.
>
> I've written a piece of JCL that issues some DFHSM commands, runs a 
> REXX to format the output, then a SORT to sort the formatted output.  
> The job fails every time.
>
> I've re-coded the job a number of times, and run the steps 
> individually, and it seems the job *only* fails when the SORT step is 
> included.
>
> Rather than post the whole job, I've discovered I can re-create the 
> failure with a really simple example.
>
> Consider the following JCL: -
>
> 
> //HSMLIST  EXEC PGM=IKJEFT1A
> //SYSTSPRT  DD  SYSOUT=*
> //SYSTSIN   DD  *
>   HSENDCMD WAIT LIST PVOL OUTDATASET('MAINT.TEMP.LIST') 
>
> This works as expected.  If 'MAINT.TEMP.LIST' doesn't exist, it gets 
> created.  If it does, the responses from the LIST PVOL command are 
> appended to the end of the dataset.  All good so far.
>
> I create a new empty dataset, 'MAINT.TEMP.TEMP', based on 
> 'MAINT.TEMP.LIST'.  I then delete 'MAINT.TEMP.LIST', and run the 
> following JCL:-
>
> 
> //HSMLIST  EXEC PGM=IKJEFT1A
> //SYSTSPRT  DD  SYSOUT=*
> //SYSTSIN   DD  *
>   HSENDCMD WAIT LIST PVOL OUTDATASET('MAINT.TEMP.LIST')
> /*
> //SORTIT   EXEC PGM=SORT
> //SYSOUTDD  SYSOUT=*
> //SORTINDD  DISP=SHR,DSN=MAINT.TEMP.LIST
> //SORTOUT   DD  DISP=MOD,DSN=MAINT.TEMP.TEMP
> //SYSIN DD  *
>  SORT FIELDS=COPY
> /*
> 
>
> The job *fails* with a JCL error.  I get the following message to my 
> terminal: -
>
> ARC0141I ERROR ALLOCATING OUTPUT DATA SET
>
> The joblog for the SORT step shows:-
>
> IEFA107I  SORTIT SORTIN - DATA SET MAINT.TEMP.LIST NOT FOUND
>
> Can anyone shed any light on what's happening here?
>
> Thanks in advance.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Stand-Alone DSS RESTORE with 3584 Library - How??

[Anthony Thompson]

Not sure if this helps... we don't have any such advanced gear.

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

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, 5 February 2016 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stand-Alone DSS RESTORE with 3584 Library - How??

On 2/4/2016 7:17 PM, Mike Schwab wrote:
> Is there any way to log in to issue a mount command within the tape library?

Not that I can find. http://publibfp.dhe.ibm.com/epubs/pdf/a3205604.pdf

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

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

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

Re: Manipulating system symbols

[Anthony Thompson]

Please note that with z/OS 2.2 the length of system symbols names has increased 
from 8 to 16, and may include the underscore character.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, 4 February 2016 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Manipulating system symbols

On 2016-02-03 19:27, Skip Robinson wrote:
> This is why I strongly recommend that installation-defined symbols be 
> prefixed with a unique string, which I also recommend be the SHARE 
> installation code. It reduces the number of meaningful character to 5 or 6 
> but pretty much rules out stepping on toes. Debugging problems caused by 
> symbol 'overlays' could be excruciating. 
>  
The namespace is too small in this 21st century.

-- gil

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

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

Re: The Linklist

[Anthony Thompson]

By system command as well as well...

SETPROG LNKLST,TEST,NAME=,MODNAME=

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Tuesday, 2 February 2016 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: The Linklist

TSO ISRFIND as well...

On Feb 2, 2016 06:10, "Paul Gilmartin" < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 1 Feb 2016 22:57:24 -0600, Ed Gould wrote:
>
> >Sounds like a SHARE requirement to me.
> >
> ???  Fixing a bug shouldn't be a SHARE requirement; it should be an SR.
>
> >On Feb 1, 2016, at 10:24 PM, Paul Gilmartin wrote:
> >
> >> Does anyone in IBM care?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: z/VM "load from dvd or server"

[Anthony Thompson]

It's been a few years... but

I think you have plugged in a z/VM install disc in the side of the Service Unit 
on the mainframe box (aka the Thinkpad) and booted it in an LPAR? 

Just go to the 'Integrated 3270 console', or just 'Operating System Messages' 
on the HMC for that LPAR and follow the prompts. It should be obvious from 
there. I've installed z/VM from a remote HMC connection, so it doesn't need an 
ICC console. All I needed was someone was to physically push the optical disc 
into the side on the mainframe. You don't need some-one with Microsoft 
Certification for that, thank goodness, otherwise you'd be re-educating someone 
on how to insert an DVD every couple of years, at a ludicrous cost.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Thursday, 28 January 2016 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/VM "load from dvd or server"

>>> On 1/27/2016 at 05:30 PM, "R.S."  wrote: 
> z/VM Installation Manual says I should first launch Integrated 3270 
> console before Load.
> Otherwise I get wait state.
> 
> Q: can I use other console instead, for example ICC console?

As long as it looks like a 3270-type console, you should be able to get it to 
work.


Mark Post

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

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

Re: MVS systrace size

[Anthony Thompson]

System command:  TRACE ST,4M

And put that in a PARMLIB COMMNDxx to set the system trace size after an IPL.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: Thursday, 10 December 2015 5:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MVS systrace size

Hello,

I am looking at the Manual to modify the MVS system trace table size.
Currently It is using 1MG per CPU.

Is there a command to dynamically enlarge systrace to 4mg per CPU ?

Could someone please point to any manuals which shows the steps to modify the 
MVS system trace table size ?

Nathan

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

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

Re: Inquire intrdr default job class

[Anthony Thompson]

No, it's a JES2 thing. And therefore you will find the mapping DSECT for $IRIS 
in SHASMAC.

I think you can chase it down from the CVT by going through CVTJESCT to find 
the first SSCT (primary JES2) -> SSCTSUS2 -> HCCT (which is a sort of CVT for 
JES2, mapped by $HCCT)

Otherwise you can get to the SSCT for JES2 by going through the SSVT.


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, 8 December 2015 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inquire intrdr default job class

On Mon, 7 Dec 2015 18:40:56 -0600, Steve Horein  wrote:

>Found this in JES2 Data Areas Volume 1:
>
>Chapter 106. $IRIS Information
>$IRIS Programming Interface Information $IRIS is a programming 
>interface.
>$IRIS Heading Information
>Common Name: IRIS
>Macro ID: $IRIS
>DSECT Name: IRIS
>
This looks like an IPCS thing.

o Is it usable outside IPCS, perhaps by chasing pointers from CVT?

o What MACLIB does it live in?

-- gil

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

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

Re: any shops hiring in DFW?

[Anthony Thompson]

Maybe the BMC Campus in Houston? No idea if they are hiring but might be worth 
a try.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Wednesday, 2 December 2015 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?

>>> On 12/1/2015 at 04:56 PM, John McKown  wrote: 
> I know it's a long shot, but does anybody know of any z/OS shops 
> around DFW who are hiring or may start in 2016? Looks like it is 
> definite that this place will be gone 2Q2016 at the very latest.

Based on what I've been seeing lately, you may wind up having to move.  If you 
do, however, I've seen a number of jobs that require mainframe skills, as well 
as Linux, and even z/VM.  Since that seems to fall into your areas of interest, 
you might want to consider it.


Mark Post

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

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

Re: s013-68 on JES2 EVENTLOG?

[Anthony Thompson]

I'm wondering if you can use PARM='SDB=INPUT' (or YES) to get IEBGENER to copy 
EVENTLOG?

I'd try to test this myself on our sandbox z/OS 2.2 system but we're not 
generating EVENTLOG datasets, even though JES2 checkpoint is at Z22 level and 
JOBDEF SUP_EVENTLOG_SMF is set to NO. Scratching my head there.

Oh, and the SDSF manual doesn't list any field in the JDS (Job Data Set) panel 
that provides block-size information, only RECFM and LRECL, so I don't think 
you can get that.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, 4 November 2015 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: s013-68 on JES2 EVENTLOG?

We just got our z/OS 2.2 system up.  So I regression tested an EXEC that 
unloads the spool files of a job to UNIX files.

It uses IEBGENER  to copy each DDNAME allocated by SDSF to a UNIX file.
It specifies no DCB attributes on SYSUT2, leaving it to IEBGENER to copy to 
SYSUT2 those supplied by SDSF.

I see a spool file I've never seen before: stepname JES2, ddname EVENTLOG, 
which fails with:

   7   8 EVENTLOG:  RECFM=U  LRECL=32760  CHARS=,,,
 IEC141I 013-68,IFG0196L,user,$STCTSO1,SYS00196
 IEA995I SYMPTOM DUMP OUTPUT
 SYSTEM COMPLETION CODE=013  REASON CODE=0068
  TIME=14.50.12  SEQ=00083  CPU=  ASID=0063
  PSW AT TIME OF ERROR  075C1000   80A26336  ILC 2  INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW  00A26330 - 4100302C  0A0D010D  A7E5014B

SDSF "SE" opens it OK with profile:
 =PROF> ISFEDIT (VARIABLE - 32760)RECOVERY ONNUMBER OFF

Why is this breaking IEBGENER?  (I don't know how to extract BLKSIZE from SDSF.)

Might it be because IEBGENER might be DCBE-ignorant?

-- gil

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

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

Re: More "ageing mainframe" (bad) press.

[Anthony Thompson]

The big one in that is the Australian Federal Government's CentreLink. They are 
attempting to replace a mainframe-based solution with a SAP solution.

The then Federal Treasurer, the esteemed Mr. Joe Hocking (now out on his arse 
after we got a new Prime Minister), claimed it was because the applications 
were running on old IBM hardware. Simply untrue, they have z196's (not the 
latest and greatest), but the applications ran on the Model 204 database.  I 
think the only other organization on the planet that still runs Model 204 
applications is the US Department of Defence.

I'm pretty sure that $1.5 billion is going to blow out to a crapload more than 
that. Here, in my 'state' government, we attempted to replace a government 
asset control suite of mainframe applications with SAP. At a projected cost of 
$5 million. $70 million of tax payers money and five years later, they gave up 
and went back to the mainframe.

Allegorically, I've heard that 70% of major mainframe applications conversions 
to little-box SAP solutions fail (a Gartner statistic?).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Friday, 25 September 2015 7:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: More "ageing mainframe" (bad) press.

http://www.itnews.com.au/news/the-top-five-green-screen-systems-that-run-australia-409614

Some large (by Aussie standards) mainframe customers that may be no more in the 
foreseeable future.

Shane ...

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

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

Re: Dataset enqueue, how to find the culprit.

[Anthony Thompson]

For trapping the results in a REXX you could use the SDSF ISFSLASH service to 
capture the results of a D GRS, RES= or D GRS,C command. I imagine you could 
use the TSO CONSOLE command too. Assuming you have the authority for either...

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, 25 September 2015 1:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

On Thu, 24 Sep 2015 14:33:03 +, Pommier, Rex wrote:
>
>Commands for viewing ENQs and ENQ contention:  
>   
>o   Enq
>Show existing ENQs on the system or systems. You can specify RNAME,
>QNAME, system name and job or user name to narrow down the search. 
> ...
Thanks.  I fear that "You can specify ..." means that when ISRDDN displays a 
panel that panel will contain fields in which to enter those options, not that 
they may be entered (from Rexx) on the command line.

Oh, I forgot to mention that I'd like to be able to OUTTRAP (or similar) the 
result for further processing.  ZSCREEN?  Probably not; my process runs 
headless.  GUIs are often overrated.

Thanks again,
gil

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

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

Re: OS/390 hard wait

[Anthony Thompson]

I stand corrected! Thanks Timothy.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Friday, 25 September 2015 2:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OS/390 hard wait

Anthony Thompson wrote:
>The earliest version of MVS (sic) that is advertised to support
>ARCHLVL=2 is z/OS 1.6

A correction: z/OS 1.6 was the first release of z/OS to *require* ARCHLVL 2 
(i.e. z/Architecture and 64-bit). OS/390 2.10 through z/OS 1.5 (inclusive) were 
bimodal and advertised as such.

My recollection is that OS/390 2.10 did not originally ship in bimodal form at 
its General Availability -- or at the very least OS/390 2.10 wasn't
*initially* advertised as bimodal. OS/390 2.10 was announced on May 16, 2000, 
several months before IBM announced the z900 on October 3, 2000.
Perhaps that helps answer Tony Thigpen's question. Maybe his customer just 
skipped applying at least some ARCHLVL 2-related updates to their OS/390
2.10 installation.

However, even with all such updates in place it still might not matter on a 
z10. The newest IBM model that supported OS/390 2.10 was the IBM z890 according 
to this table:

http://www.ibm.com/systems/z/os/zos/support/zos_server_support.html

z/VM 6.3 never supported the z890 -- z/VM Version 6 requires a z10 or higher -- 
and thus also never supported OS/390 2.10 as a guest. So if
OS/390 2.10 runs in z/VM 6.3 on a z10 it's accidentally fortuitous, or 
fortuitously accidental, even with the final and complete set of OS/390
2.10 updates in the mix.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: OS/390 hard wait

[Anthony Thompson]

The earliest version of MVS (sic) that is advertised to support ARCHLVL=2 is 
z/OS 1.6

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Friday, 25 September 2015 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: OS/390 hard wait

In a DR site, we are 'playing' with a customers OS/390 2.10 under z/VM
6.3 on a z10.

Their system was running with ARCHLVL=1, but we were having some performance 
issues, so we decided to see what would happen with ARCHLVL=2.

The initial IPL trucks along until it the console switches modes. Then the 
guest enters:

"CP disabled wait PSW 0002 8000  9064"

Console:
IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNPF5 INITIALIZATION

Thoughts?

--
Tony Thigpen

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

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

Re: IPL Shutdown Problem

[Anthony Thompson]

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

Re: IPL Shutdown Problem

[Anthony Thompson]

ROUTE command not working is a completely separate issue. It won't happen if 
that LPAR is outside of the sysplex. You'll need a console on that system. Use 
the HMC if you need to, assuming you have one. 

Try the F OMVS, STOPPFS=FZS command on a SYS9 console. F 
BPXOINIT,SHUTDOWN=FORKINIT should bring down both ZFS and OMVS.

$PJES2,ABEND if you absolutely have to.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

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

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

Re: IPL Shutdown Problem

[Anthony Thompson]

Most typically, that wait state is entered when the system has been 
deliberately shut down by operators.

Re-IPL.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Hi Ant,

We couldn't able to access commands from master console or HMC, since the 
system went onto wait-state.

Central processor (CP) 0 is in a nonrestartable stopped state due to a System 
Control Program (SCP) initiated reset of the I/O interface for partition LPAR4. 
The disabled wait program status word (PSW) is 0002800040a2.

Could you assist how we move forward from here. Thanks

Regards,
Vinoth M

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

ROUTE command not working is a completely separate issue. It won't happen if 
that LPAR is outside of the sysplex. You'll need a console on that system. Use 
the HMC if you need to, assuming you have one. 

Try the F OMVS, STOPPFS=FZS command on a SYS9 console. F 
BPXOINIT,SHUTDOWN=FORKINIT should bring down both ZFS and OMVS.

$PJES2,ABEND if you absolutely have to.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

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

--
F

Re: IDCAMS DELETE MASK and Recalls

[Anthony Thompson]

Created eleven datasets, ANT.DELETE.TEST, where  was  to 0010.

Migrated the first 5 files (TEST000 to TEST0004) yes, used IBM's HSM, and 
on a z/OS 2.1 LPAR.

Ran an IDCAMS job to delete the files, output from job was:

  DELETE   ANT.DELETE.** MASK 
IDC0550I ENTRY (A) ANT.DELETE.TEST0005 DELETED
IDC0550I ENTRY (A) ANT.DELETE.TEST0006 DELETED
IDC0550I ENTRY (A) ANT.DELETE.TEST0007 DELETED
IDC0550I ENTRY (A) ANT.DELETE.TEST0008 DELETED
IDC0550I ENTRY (A) ANT.DELETE.TEST0009 DELETED
IDC0550I ENTRY (A) ANT.DELETE.TEST0010 DELETED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 

No mention of the first five migrated files, which were successfully 
HDELETE'ed, with no HSM-recall involved.

From the JESYSMSG file:

IGD103I SMS ALLOCATED TO DDNAME SYS1
IGD104I ANT.DELETE.TEST0005 
IGD103I SMS ALLOCATED TO DDNAME SYS2
IGD104I ANT.DELETE.TEST0006 
IGD103I SMS ALLOCATED TO DDNAME SYS3
IGD104I ANT.DELETE.TEST0007 
IGD103I SMS ALLOCATED TO DDNAME SYS4
IGD104I ANT.DELETE.TEST0008 
IGD103I SMS ALLOCATED TO DDNAME SYS5
IGD104I ANT.DELETE.TEST0009 
IGD103I SMS ALLOCATED TO DDNAME SYS6
IGD104I ANT.DELETE.TEST0010 

Cheers, Ant.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, 20 August 2015 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDCAMS DELETE MASK and Recalls

We have CA-DISK as a HSM replacement. I like to be sure where to report this as 
a problem.

Is anybody willing to check if IDCAMS DELETE MASK is working under z/OS V2.1:
- with standard HSM
- with CA-DISK as an HSM replacement?

//DELETE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
 DELETE A.B.* MASK

Thanks,
Kees.

-Original Message-
From: Vernooij, CP (ITOPT1) - KLM
Sent: 20 August, 2015 8:07
To: IBM Mainframe Discussion List
Subject: RE: IDCAMS DELETE MASK and Recalls

John,

Thanks, I will.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: 19 August, 2015 18:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDCAMS DELETE MASK and Recalls

kees.verno...@klm.com (Vernooij, CP - KLM , ITOPT1) wrote:
 Hello,

 Some time ago we got the great enhancement that IDCAMS DELETE did not recall 
 a dataset anymore.
 Then we got the great enhancement to easily delete large amount of datasets 
 with IDCAMS DELETE MASK.

 However, DELETE MASK appears to recall the datasets again. Is this as 
 intended, and documented? Why can't we have both great enhancements together?

I forwarded your post to the developer, who was surprised, because the data 
sets should not be recalled by IDCAMS DELETE.  He asks that you open a PMR.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

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

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

Re: Product Remove from z/OS

[Anthony Thompson]

Ah. After checking, I see that fmid's H0B5110, H0B7110 and H0Z2110 (the REXX 
stuff) is common to CICS TS V3, CICS TS V4 and is still in CICS TS V5.

So make sure you know which fmid's you really want to get rid of from which 
zones.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Friday, 10 July 2015 10:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product Remove from z/OS

I don't like your ++VER statement.

Firstly, the srel should be C150 (CICS), Z038 is for z/OS. 

Secondly, depending on what elements you have installed, you'll want to delete 
more than fmid HCI6400 . 

From the CICS TS 3.1 program directory ( 
http://publibfp.dhe.ibm.com/epubs/pdf/i1025860.pdf ) :

HCI6400 - CICS TS Base
JCI6401 - COBOL Language Parts
JCI6402 - PL/I Language Parts
JCI6403 - C Language Parts and XPLINK
JCI640D - IIOP/JAVA
HCP3100 - CICSPLEX SM V3R1 (z/OS and OS/2 Remote MAS Support, CMAS and local 
MAS Support)
JCP3102 - CICSPLEX SM V3R1 (SAS components)
HBDD110/0103 - CICS Application Migration Aid
H0B5110/0103 - CICS REXX Runtime Facility
H0B7110/0103 - CICS REXX Development System
H0Z2110/0103 - CICS REXX Common for CICS/ESA
HCIZ100/0103 - CICS Integrator Adapter for z/OS

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Friday, 10 July 2015 1:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product Remove from z/OS

Hello,
  Thanks for suggestion. We coded  something like below for 
removing those FMID from both target and distribution zone of CICS .


//FMIDDEL JOB ,,CLASS=A,MSGCLASS=A,REGION=0M,NOTIFY=SYSUID
//S1   EXEC PGM=GIMSMP,
// PARM='PROCESS=WAIT',
// DYNAMNBR=120
//SMPCSI   DD DISP=SHR,DSN='SMPE.CICS.GLOBAL.CSI'
//SMPHOLD  DD DUMMY
//SMPLOG   DD  SYSOUT=*
//SMPOUT   DD  SYSOUT=*
//SMPRPT   DD  SYSOUT=*
//SMPLIST  DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SMPPTFIN DD *
++FUNCTION  (MSZ0001) REWORK(2015100)
/***/
/* DELETE HCI6400 FROM ALL ZONES   */
/***/
.
++VER   (Z038)
DELETE(HCI6400) .
/*
//SMPCNTL  DD *
  SETBOUNDARY (GLOBAL).
  RECEIVE SELECT (MSZ0001) SYSMOD.
  SETBOUNDARY (CICS31T) .
  APPLY   SELECT (MSZ0001) .
  SETBOUNDARY (CICS31D) .
  ACCEPT  SELECT (MSZ0001) .
  SET  BOUNDARY(CICS31T) .
  UCLIN.
  DEL SYSMOD(MSZ0001).
  DEL SYSMOD(HCI6400).
  ENDUCL.
  SET  BOUNDARY(CICS31D) .
  UCLIN.
  DEL SYSMOD(MSZ0001).
  DEL SYSMOD(HCI6400).
  ENDUCL.
  SETBOUNDARY (GLOBAL).
  REJECT  APARS FUNCTIONS PTFS USERMODS FORFMID(HCI6400).
  RESETRC.
  UCLIN.
  DEL  GLOBALZONE FMID(MSZ0001).
  DEL  GLOBALZONE FMID(HCI6400).
  ENDUCL.
/*


Please correct, If I made any mistake in this or Am I following wrong path.

On Thu, Jul 9, 2015 at 8:08 PM, Kurt Quackenbush ku...@us.ibm.com wrote:

 SET BDY(GLOBAL).
 UCLIN.
 DEL DZONE(CIC31D) .
 ENDUCL.


 No, this will give you a syntax error.  To remove from the global zone 
 the pointers to the target and dlib zones you wish to delete, do this instead:

 SET BDY(GLOBAL).
 UCLIN.
 DEL GZONE ZONEINDEX((CIC31D, CIC31T)).
 ENDUCL.


 Kurt Quackenbush -- IBM, SMP/E Development

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


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

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

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

Re: Product Remove from z/OS

[Anthony Thompson]

I don't like your ++VER statement.

Firstly, the srel should be C150 (CICS), Z038 is for z/OS. 

Secondly, depending on what elements you have installed, you'll want to delete 
more than fmid HCI6400 . 

From the CICS TS 3.1 program directory ( 
http://publibfp.dhe.ibm.com/epubs/pdf/i1025860.pdf ) :

HCI6400 - CICS TS Base
JCI6401 - COBOL Language Parts
JCI6402 - PL/I Language Parts
JCI6403 - C Language Parts and XPLINK
JCI640D - IIOP/JAVA
HCP3100 - CICSPLEX SM V3R1 (z/OS and OS/2 Remote MAS Support, CMAS and local 
MAS Support)
JCP3102 - CICSPLEX SM V3R1 (SAS components)
HBDD110/0103 - CICS Application Migration Aid
H0B5110/0103 - CICS REXX Runtime Facility
H0B7110/0103 - CICS REXX Development System
H0Z2110/0103 - CICS REXX Common for CICS/ESA
HCIZ100/0103 - CICS Integrator Adapter for z/OS

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Friday, 10 July 2015 1:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product Remove from z/OS

Hello,
  Thanks for suggestion. We coded  something like below for 
removing those FMID from both target and distribution zone of CICS .


//FMIDDEL JOB ,,CLASS=A,MSGCLASS=A,REGION=0M,NOTIFY=SYSUID
//S1   EXEC PGM=GIMSMP,
// PARM='PROCESS=WAIT',
// DYNAMNBR=120
//SMPCSI   DD DISP=SHR,DSN='SMPE.CICS.GLOBAL.CSI'
//SMPHOLD  DD DUMMY
//SMPLOG   DD  SYSOUT=*
//SMPOUT   DD  SYSOUT=*
//SMPRPT   DD  SYSOUT=*
//SMPLIST  DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SMPPTFIN DD *
++FUNCTION  (MSZ0001) REWORK(2015100)
/***/
/* DELETE HCI6400 FROM ALL ZONES   */
/***/
.
++VER   (Z038)
DELETE(HCI6400) .
/*
//SMPCNTL  DD *
  SETBOUNDARY (GLOBAL).
  RECEIVE SELECT (MSZ0001) SYSMOD.
  SETBOUNDARY (CICS31T) .
  APPLY   SELECT (MSZ0001) .
  SETBOUNDARY (CICS31D) .
  ACCEPT  SELECT (MSZ0001) .
  SET  BOUNDARY(CICS31T) .
  UCLIN.
  DEL SYSMOD(MSZ0001).
  DEL SYSMOD(HCI6400).
  ENDUCL.
  SET  BOUNDARY(CICS31D) .
  UCLIN.
  DEL SYSMOD(MSZ0001).
  DEL SYSMOD(HCI6400).
  ENDUCL.
  SETBOUNDARY (GLOBAL).
  REJECT  APARS FUNCTIONS PTFS USERMODS FORFMID(HCI6400).
  RESETRC.
  UCLIN.
  DEL  GLOBALZONE FMID(MSZ0001).
  DEL  GLOBALZONE FMID(HCI6400).
  ENDUCL.
/*


Please correct, If I made any mistake in this or Am I following wrong path.

On Thu, Jul 9, 2015 at 8:08 PM, Kurt Quackenbush ku...@us.ibm.com wrote:

 SET BDY(GLOBAL).
 UCLIN.
 DEL DZONE(CIC31D) .
 ENDUCL.


 No, this will give you a syntax error.  To remove from the global zone 
 the pointers to the target and dlib zones you wish to delete, do this instead:

 SET BDY(GLOBAL).
 UCLIN.
 DEL GZONE ZONEINDEX((CIC31D, CIC31T)).
 ENDUCL.


 Kurt Quackenbush -- IBM, SMP/E Development

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


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

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

Re: Product Remove from z/OS

[Anthony Thompson]

All that UCLIN does is get rid of the GLOBAL zone pointers to the 
Tzone/Dzone's. It does nothing to the tzone/dzone themselves or to the 
(presumably separate) VSAM clusters that contain those Tzone/Dzone's. You can 
delete the VSAM clusters either before or after, it doesn't matter, since the 
UCLIN only touches the global zone.

Before doing that, have you applied/ accepted all maintenance for the version 
of CICS you're trying to get rid of? So there's nothing relevant left in the 
SMPPTS, SCDS, MTS, LTS, STS?

In any event, simply deleting the tzone/dzone doesn't lose all information 
about the CICS you're trying to get rid of. The Global zone will still have 
product and feature entries.

You've already been told how to do it, by Craig Pace. Code a usermod with 
++DELETE MCS for the CICS fmid's and receive/apply/accept that usermod (yes, 
accept a usermod! This is about the only situation I would do so).

Lastly, why do you have a global zone for all versions of CICS? When I install 
the next version of CICS, I create an entirely new SMP/E environment, with its 
own global zone. I don't see any advantage to your approach.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mainframe Mainframe
Sent: Thursday, 9 July 2015 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Product Remove from z/OS

Hello,
 Thanks for suggestion.

1) We already have new version of CICS running under same global zone along 
with older CICS version still running.
2) My idea is to remove older CICS version from my z/OS systems.
3) We already have weekly back, So we are good in this case.
4) cics-fmids was not actual FMID, that was just for reference, I used in email.
5) As per your suggestion, I understood that , If I use

SET BDY(GLOBAL).
UCLIN.
DEL DZONE(CIC31D) .
ENDUCL.

and same with target

SET BDY(GLOBAL).
UCLIN.
DEL DZONE(CIC31T) .
ENDUCL.

Doing this will remove all entries from my global zone  and later I can delete  
target and distribution CSI attached to these two CIC32T and CIC31D. Or do I 
have to delete these CSI dataset first using IDCAMS and then use above operand 
to delete both of these zones.


Please suggest.


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

Re: Leap Second today!

[Anthony Thompson]

It depends on how much a z/OS site needs, or doesn't need, precise timing. 
Server Timer Protocol can add a leap second at the appropriate time (goes into 
a wait for the second), or it can gradually 'steer' the time over seven hours, 
gradually correcting the system time.

Attached is nice document that explains STP's handling of leap seconds in 
fairly gentle terms.

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

So the answer to both questions isn't necessarily Yes, and that's not 
necessarily a bug. 

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, 3 July 2015 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

On Thu, 2 Jul 2015 13:36:26 -0400, Ed Finnell wrote:

Yikes. Too much hasenpfeffer...

http://www.wired.com/2012/07/leap-second-glitch-explained/

In my time zone, the leap second occurred at 17:59:60.  So, I wonder about the 
z/OS STIMER macro:

If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01]
would the wait have expired in 3 seconds?

If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
would the wait have expired at 18:00:01?

Unless the answer to both questions is Yes, there's a bug.

-- gil

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

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

Re: [DB2-L] - ICF catalog management for a new DB2 subsystem

[Anthony Thompson]

Catalog performance generally isn't any kind of problem if you are using 
Enhanced Catalog Sharing, or, better, Record Level Sharing on the catalogues. 
Having said that, catalogues shouldn't get so large that they use more than one 
index level.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Saturday, 9 May 2015 2:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [DB2-L] - ICF catalog management for a new DB2 subsystem

Hi Liz

I thought have different component of DB2 in different user catalog might 
improve the performance.

Jake
On 8 May 2015 20:22, Lizette Koehler stars...@mindspring.com wrote:

 Jake,

 We use one HLQ for most of the DB2 data sets on z/OS.  ICFCATALOGs are 
 only defined once for all DB2 environments.  We do not define a new 
 catalog with upgrades or new installs.  Only one Usercat.  An ICF Cat 
 belongs to SMS and not DB2 environment.  I would expect it to 
 following the same standards that your shop currently uses for any product 
 that has an HLQ.



 I think this will depend more one your recovery and DR processes at 
 your shop.



 Please let us know what your understanding of IC F Catalogs and their 
 usage.



 Lizette





 From: jake anderson [mailto:db...@lists.idug.org]
 Sent: Friday, May 08, 2015 6:47 AM
 To: db...@lists.idug.org
 Subject: [DB2-L] - ICF catalog management for a new DB2 subsystem



 Hello,

 Cross Posted in IBM MAIN

 Could you please let me know on how you use the ICF catalog to manage 
 the
 DB2 install ? Like do you maintain a seperate ICF for BSDS, LOGCOPY ?

 Any best practises followed on managing the ICF catalog during any DB2 
 installs ?

 Any advises or suggestion are highly appreciated.



 Regards,

 Jake

   _


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


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

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

Re: Ads in Redbookd.

[Anthony Thompson]

Ditto.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Friday, 17 April 2015 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ads in Redbookd.

How long have we had ads (sorry, Promotions) in Redbooks ?.
Just pulled the z13 Tech Intro Ed posted about - can't be that long since I 
downloaded one, and I certainly don't recall included ads.
As bad as the bloody trailers on hired DVDs.

quote
Imagine the power of being seen by users who download millions of Redbooks 
publications each year!
quote
H ... rather; imagine potentially pissing off all those users.

Shane ...

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

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

Re: /tmp issue

[Anthony Thompson]

As mentioned, thoroughly inappropriate to use /tmp for mass Serverpac 
/ShopzSeries  downloads or decompressions. I have always used a personal zFS 
for such purposes (SMPNTS, or SMPWKDIR). Which can be easily 
re-sized/re-mounted depending on needs.

I'm wondering what the OP thinks SYSTEM/tmp is for (if sysplex-wide, otherwise 
just /tmp) , especially when it is directed to virtual storage. That's a 
performance thing for particular reasons, not a mindless convenience.  

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Conley
Sent: Friday, 17 April 2015 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: /tmp issue

On 4/16/2015 5:18 PM, Staller, Allan wrote:
 This is a TFS (TEMP FILE SYSTEM)  and is backed by virtual storage.  You need 
 approx.. 600 MB of space.

 I would recommend allocating a PFS (Physical File System) large enough to 
 hold the 600 MB and mounting that PFS at /TMP.

 Once done, the PFS can be handled by use of AGGGROW and AGGRINFO. See the 
 Distributed  File Services manual  SC23-6887-00 (for z/OS 2.1).

 An IPL should not be necessary for the above.

 BTW, when you go to expand the SERVERPAC files, you will need approx. 3 times 
 the space needed for download.

 HTH,



 snip
 I am trying to down load datasets from serverpac. I am getting this message :

 6831167  kbytes are required.

 Please obtain more space before attempting restore.

 My /tmp file is as follows:

 /SYSTEM/tmp

 ,
 Status . . . . . . . . :,Available
 File system type . . . :,TFS
 Mount mode . . . . . . :,R/W
 Device number  . . . . :,2
 Type number  . . . . . :,1
 DD name  . . . . . . . :,
 Block size . . . . . . :,4096
 Total blocks . . . . . :,1792000
 Available blocks . . . :,1543002
 Blocks in use  . . . . :,248998
 /snip


I read the space required as 6.9GB, so you'll need a mod-9 to hold your file.  
I recommend creating an /SMPNTS mount point, mounting your filesystem there, 
then downloading the ServerPac.  As Allan pointed out, you will likely need at 
least 3 more mod-9s to unspin those tarballs.

Regards,
Tom Conley

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

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

Re: Catalog Recovery Software

[Anthony Thompson]

Is CIM (from both ASPG and Hostsystems GmbH) the one and same product? Supplier 
dependent on country?

Of course, there is always the free ICFRU, documented in the IBM Managing 
Catalogs manual.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Thursday, 16 April 2015 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Catalog Recovery Software

Substantially the same question was asked in this forum in 2009. See this
thread:

https://www.mail-archive.com/ibm-main@bama.ua.edu/msg102501.html

Or, to save you from reading the thread, here's the complete list of tools 
mentioned in that thread:

IBM: Tivoli Advanced Catalog Management for z/OS (possibly also Tivoli Advanced 
Audit for DFSMShsm, depending on requirements)

ASPG: Catalog Information Manager (CIM)

CA: CREWS

Data Processing Techniques: DP Technician

Dino-Software: T-REX

EMC: Catalog Solution (formerly Softworks, formerly VSAM Mechanic)

Estorian: SpaceFinder

Hostsystems GmbH: Catalog Information Manager (CIM)


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: murach's os/390 and z/os jcl pdf

[Anthony Thompson]

Exactly. The OP is looking for a free ride. I will also point out that the book 
is somewhat dated,  and there have been improvements to JCL since (access to 
system symbols, promotion of such to SYSIN, PARMDD, etc.).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, 10 April 2015 10:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: murach's os/390 and z/os jcl pdf

On Fri, 10 Apr 2015 01:49:23 -0400, Rajesh Kumar wrote:

Anybody have pdf of murach's os/390 and z/os jcl ?, if so please share 
to me.

I been searching  free copy this book

If you want free, what's wrong with the JCL Reference and the JCL User's Guide?

--
Tom Marchant

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

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