Re: SMP/E

[Longabaugh, Robert E]

CA has offered Internet Service Retrieval (RECEIVE ORDER) since January 2018.   
https://support.ca.com/us/product-content/status/announcement-documents/2018/ca-smp-e-receive-order---maintenance-delivery-made-easy.html
 
I believe that at least one other ISV offers RECEIVE ORDER, but do not want 
name the wrong one.

The most recent MVS Packaging Rules that I know of is for SMP/E 3.5.  It does 
have rules to build your function sysmods that would apply to any delivery 
vehicle.  There is also some documentation that applies to service sysmods as 
well, for example if you are creating a new load module or adding a module to 
an existing load module.

Bob Longabaugh
CA Technologies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, October 24, 2018 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


On Wed, 24 Oct 2018 15:02:07 -0400, Tony Harminc wrote:
>
>Fundamental question is whether you are more interested in using SMP/E 
>for managing other peoples' software/maintenance/etc, or in using it to 
>package up your own stuff for other people to use.
>
>Since (I believe) you work for an ISV, I'm guessing the latter. You 
>certainly need to look at the SMP/E z/OS Packaging Rules, SC33-3695. 
>Strangely this seems to have fallen out of the SMP/E doc set. In any 
>case, it's very much a reference and not a tutorial, but does contain 
>"best practices" and such.
>
Did that publication ever mature beyond beyond being tape-centric?
(Remember tapes?)  The chapter on GIMZIP in the SMP/E Ref. describes packaging 
for RECEIVE FROMNETWORK/FROMNTS.  AFAIK, IBM has never supported ISV packaging 
for RECEIVE ORDER.

-- 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: SMP/E

[Longabaugh, Robert E]

SMP/E is very well documented by IBM and you can find much of what you need 
from the basic manual set.

Commands Guide describes the processing steps for each command, including what 
is done for different element types on receive, apply and accept, and how SMP/E 
builds load modules.
Reference Guide has the syntax for different types of MCS (++ statements).  It 
also has documentation for all SMP/E related DDNAMEs, for the API, and some 
service routines.
The User's Guide does get into basic explanation and tutorial.  For ISVs, it 
provides a good view of how customers would expect SMP/E to work.
Messages Guide is what it sounds like.

The Rules for Packaging mentioned by Tony is a good reference for ISVs.  It 
addresses Function Sysmods (releases) more than APARs/PTFs.

SRA did provide the SMP/E Fundamentals in the mid-1990s.   We have a copy 
inherited from Sterling Software but it is on twelve 3.5 inch disks.

Bob Longabaugh
CA Technologies 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Wednesday, October 24, 2018 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


On 24 October 2018 at 10:41, scott Ford  wrote:

> I never had to use SMP/E in my career except for simple items, like 
> Receives, Applies , etc.
> Now I am in a situation that need more detailed information a 
> (self-study) would be really appreciated. Can anyone help me out, point me to 
> one ?

Fundamental question is whether you are more interested in using SMP/E for 
managing other peoples' software/maintenance/etc, or in using it to package up 
your own stuff for other people to use.

Since (I believe) you work for an ISV, I'm guessing the latter. You certainly 
need to look at the SMP/E z/OS Packaging Rules, SC33-3695. Strangely this seems 
to have fallen out of the SMP/E doc set. In any case, it's very much a 
reference and not a tutorial, but does contain "best practices" and such.

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: Question on DISP=MOD and GDGs

[Longabaugh, Robert E]

Messages like *** WARN 04 and !!!ERROR 04 are probably not coming from IBM or 
an ISV.   

However, customers can write messages like that from the IBM ACS routine or 
from an allocation manger like CA Allocate DASD Space and Placement or some of 
the other competitors in that area which were mentioned on another thread 
earlier today.  There are also JCL checking ISV products like CA JCLCheck, and 
the job scheduling products like CA 7 or CA Workload Automation ESP Edition 
which might also be used produce a message like that.

If those appeared in the IDCAMS output, it would probably be the JCL checker or 
scheduling product.  The messages from allocation manager would normally appear 
in the JES log.

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Friday, October 05, 2018 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question on DISP=MOD and GDGs

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


List -

I am having a discussion on how a GDG is handled based on the DISP.  I was 
always working from the position that the use of MOD changes JCL behavior 
slightly with a dataset.  My understanding is:  If using MOD then if the 
dataset does not exist, it is treated as NEW and if it exists then treated as 
OLD.  That seems reasonable, however, I have some users coding this for GDGs 
and I am not sure why they should work.


Now the following are samples and I am sure there are other coding that I have 
not included.



So based on the following, which should be considered incorrect coding

1) First time creating the new Daily dataset.  There is also a concern on the 
second coding


//SMFOUT DD DSN=SMFHLQ.DAILY.SMFDSN(+1),
// DISP=(MOD,CATLG,DELETE),
// STORCLAS=NONSMS,EXPDT=99000,
// RECFM=VBS,BLKSIZE=32000,LRECL=32760,BUFNO=10,
// UNIT=TAPE
*** WARN 04: DISP FOR NEW GDG DATASET IS NOT (NEW,CATLG)

Appending SMF data daily dataset

//SMFOUT DD DSN=SMFHLQ.DAILY.SMFDSN(0),
// DISP=(MOD,CATLG,DELETE
*** WARN 04: DISP FOR NEW GDG DATASET IS NOT (NEW,CATLG)



2)  Using BR14 with MOD DELETE for a GEN that has NOT been created

//S1 EXEC PGM=IEFBR14
//GDGBASE DD
DISP=(MOD,DELETE,DELETE),DSN=TSOHLQ.GDGTEST(0),SPACE=(TRK,(1,1)),UNIT=SYSDA
!!!ERROR 04: GDG(0) NOT PERMITTED WITH DISP=NEW


GDG does not have any GENs yet.  So get the following

//COPYIT1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//*
//*
//SYSIN DD DUMMY
//SYSUT2 DD DISP=(MOD,CATLG,DELETE),UNIT=SYSDA,
// SPACE=(CYL,(1,1),RLSE),
// DSN=TSOHLQ.GDGTEST(+1)
*** WARN 04: DISP FOR NEW GDG DATASET IS NOT (NEW,CATLG)
//SYSUT1 DD *
 TEST RECORD


The GDG has one generation in the base I am able to see this should work

   //
   //*
   //
   //S1 EXEC PGM=IEFBR14
   //GDGBASE DD DISP=(MOD,DELETE,DELETE),DSN=TSOHLQ.GDGTEST(0)


I am not saying these are great ways to code DISP=MOD, just that I have seen 
this coding work but have been told that they should not work or they would 
cause weird/crazy results


Any and all opinions welcome.



Thanks


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: S106 abends after copying into LINKLIST

[Longabaugh, Robert E]

" Now my memory is fading, what is the name of that third party product which 
could intercept x37 abends and then dynamically fix it for you? "

CA Allocate does that and many other things.   Another ISV markets the one you 
are thinking of, and its name matches up with what you said it does.

Just trying to help

Bob Longabaugh
CA Technologies
Storage Management



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Friday, October 05, 2018 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S106 abends after copying into LINKLIST

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


John Eells wrote:

>I expect that we will err on the side of more free space pretty soon to help 
>alleviate out of space problems in this new(er) era of larger system software 
>volumes, particularly because system software is such a small fraction of the 
>disk space requirements for nearly any shop out there.

Indeed.


>System software data set level space management and x37 abends during APPLY 
>and ACCEPT processing will, I would hope, become a fading memory in a few 
>years.

Now my memory is fading, what is the name of that third party product which 
could intercept x37 abends and then dynamically fix it for you?


>Unlike some other memories, nobody will miss the "good old days."  This will 
>be more like the stories about how much more complicated life used to be when 
>you had to walk to school.  It was always uphill both ways and it was always 
>cold and snowing.  At least, that's what people used to tell their kids who 
>rode those cushy heated (FSVO "heated," at least in Maine) buses, right?

Right. In my child days, we were so poor, we have:

1. Running water - you run outside to get water using your pail and your feet.
2. cold and hot water - cold in the winter, hot in the summer.
3. shools have a tree structure - you just sit under a tree.
4. good transport - donkey car, cycle or just walking.
5. excellent entertainment - you just play outside.
6. But food was at least good - no junk food like those fast take aways.
7. I wish I could remember the rest, but my memory is fading... ;-)

John, thanks for your kind and educational posts. I really value them. Please 
continue sharing your wisdom.

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: COBOL Cowboys

[Longabaugh, Robert E]

Big mistake in this article where they say IBM "makes the computers that run on 
COBOL".  This should be "makes the computers that run COBOL programs".  I can't 
find a place to comment or email the author.

Bob Longabaugh
CA Technologies
Storage Management 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, October 04, 2018 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL Cowboys

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Why Westerns may ride back into town after sunset.

https://urldefense.proofpoint.com/v2/url?u=https-3A__uk.reuters.com_article_uk-2Dusa-2Dbanks-2Dcobol-2DidUKKBN17C0DZ&d=DwIFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=wioJ6rDoqUpds6uGjH6r_Z3GUz7TN2PJYcmnCat8zyo&s=QMXTjUOmnw3Sv_oCDwfbhwWHAkgsW2b5Rd7VKU1Ftu0&e=

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


--
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: (OT) Good bye everyone

[Longabaugh, Robert E]

I am sorry to hear of this Ed.  Thanks for your contributions to this list.  It 
is my sincere hope that you can find new and rewarding challenges to address.

Bob Longabaugh
CA Technologies 
Storage Management Products



  From: Edward Gould 
 To: IBM-MAIN@LISTSERV.UA.EDU
 Sent: Monday, July 16, 2018 3:23 PM
 Subject: (OT) Good bye everyone

Approximately 2 months I had a life altering incident.
I can no longer function as a sysprog. I resigned my no pay job at the place I 
used to donate my time.
I find I can no longer do the job.
I hope much success to all of you and hope that you can carry on with your 
work, despite IBM’s best efforts to do away with the profession.
Thanks, to John Ells and the many other IBMer’s who give their time and their 
experience with IBM-MAIN.
Not sure what is ahead for me, other than traveling with a companion as I can 
barely walk.
I am 70 years old and I am finding life without a technical challenge not 
interesting and since I can no longer function in that capacity I will have to 
find some other outlet.
Best wishes to you all.

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

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

Re: Weirdest. Acquisition. Ever. Broadcom buys CA Technologies • The Register

[Longabaugh, Robert E]

Before CA, I worked for the telephone company that bought ADR and then sold it 
to CA two years later.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, July 12, 2018 4:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Weirdest. Acquisition. Ever. Broadcom buys CA Technologies • The 
Register

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Hmm. We have a few CA products, but our entire enterprise is constructed around 
Brocade switches. Oh my.

.
.
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 Mark Regan
Sent: Thursday, July 12, 2018 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fwd: Weirdest. Acquisition. Ever. Broadcom buys CA 
Technologies • The Register

$19bn to meld chipmaker and software museum into mission-critical amalgam

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.theregister.co.uk_2018_07_12_broadcom-5Fca-5Ftechnologies_&d=DwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=6zNoPuE0N_hLYKeofJ9LZgkB6rv_8lr7pYQuJ1T0eGc&s=ryjI1J6b3p3RKF-0CEpAaxm1CW30gwCKPjdvwRXhUCw&e=


--
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: Allocating VSAM in JCL was Re: z/OS JCl vs. VSE JCL: VSAM files

[Longabaugh, Robert E]

I use JCL VSAM for CA Allocate testing

This example was for an in-house program and is from 2005, so 13 years ago 
sounds right.  Obviously KEYLEN and KEYOFF are only needed for RECORG=KS.
//PTFXREF   DD   DISP=(,CATLG,DELETE),DSN=&SYSUID..PTFXREF, 
//  STORCLAS=TSO,   
//  LRECL=206,KEYLEN=7,KEYOFF=0,RECORG=KS,  
//  SPACE=(TRK,(10,10)) 


TSO ALLOC can also create VSAM files.  TSO DEFINE would be easier, but 
different syntax.
ALLOC DA('TST.XYZ.LDS') -   
 NEW CATALOG  -  
 TRACKS -
 SPACE(5 5) -
LRECL(4096) -
RECORG(LS) - 
DATACLAS(LDS) -
STORCLAS(SMSLDS) -  
DSNTYPE(EXTREQ) -
DSKEYLBL(TEST.KEY)






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Wednesday, July 11, 2018 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Allocating VSAM in JCL was Re: z/OS JCl vs. VSE JCL: VSAM files

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


[Default] On 10 Jul 2018 15:33:56 -0700, in bit.listserv.ibm-main 
johnrcl...@gmail.com (John Clifford) wrote:

>it is not the default but is the only correct way to access a vsam file.
>disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
>
>Never disp=new or delete.   Disp=old can be used if you need to make sure
>you are the only one accessing the file but if it is open in CICS it 
>will hang.

As of over 13 years ago, you could allocate a VSAM file in JCL and even a 
temporary one.  I never used the facility but it is there.

Clark Morris
>
>On Tue, Jul 10, 2018 at 6:07 PM, Tony Thigpen  wrote:
>
>> So, DISP=SHR is not the default, as I thought was implied by John's 
>> statement that "Z/os VSAM is always accessed as DISP=SHR."
>>
>> Tony Thigpen
>>
>> Gibney, Dave wrote on 07/10/2018 05:49 PM:
>>
>>> If DISP=SHR (that is if not DISP is provided), then the JCL Default 
>>> of
>>> (NEW,PASS) would happen and the job would fail
>>>
>>> -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
 Sent: Tuesday, July 10, 2018 2:43 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

 Then, why does every VSAM DD for every z/OS site I have worked 
 with, always include DISP=SHR?
 (I guess, because it's a habit from non-VSAM files and nobody told 
 them they did not have to do it.)

 Tony Thigpen

 John Clifford wrote on 07/10/2018 04:16 PM:

> Z/os VSAM is always accessed as  DISP=SHR.
>

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

--
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] Old School Maintenance Philosophy -- Never ACCEPT?

[Longabaugh, Robert E]

From an ISV standpoint, we come across this from time to time.  I suppose that 
this is to avoid the chance of needing to back out to a level earlier than they 
accepted.   However, at times the distribution zone for our product winds up 
lower than the level needed to support the z/OS currently in their site.  

Bob Longabaugh
CA Technologies
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Thursday, May 24, 2018 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


VSAM came out in the same time frame as SMP, Yes, pre-ICF VSAM had some issues, 
but the way that SMP misused member name was a true gargoyle.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=Qtc7CRLhR62m9Vglr6iyfbkAN62o5ohE_t06AvB1jyg&s=_iP0gQfCrV5cvBwSr_aeLuT6mLZoVSd29bf9vk1_rng&e=


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, May 23, 2018 5:30 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

Pre-E SMP consisted entirely of PDS--PO because PDSE had not been invented yet. 
It was, as someone pointed out, a sort of elaborate RYO data base. In those 
days of molasses-inspired SLED, clunky CPUs, limited expensive central memory, 
and a far less sophisticated MVS than we enjoy today, a 'standard' SMP install 
could take forever. Hours. Days. Longer even than the MTTF of the 
infrastructure itself.

So SMP provided an alternative run mode. I forget the terminology, but it 
entailed reading entire PDS directories into memory, updating data in memory as 
required, then writing entire directories back out in one massive operation. 
The result was a far shorter elapsed time than the standard mode. Unless. 
Unless something went wrong, especially during the write-out phase. Could be a 
program failure; DASD error; power hiccup, spilled cup of coffee. At that point 
the entire SMP data base was trashed. So you restored the whole SMP environment 
and started over.

With or without ACCEPT, modern SMP/E is a miracle.

.
.
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 Seymour J Metz
Sent: Wednesday, May 23, 2018 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [External] Old School Maintenance Philosophy -- Never 
ACCEPT?

>SMP/E for z/OS  IBM User's Guide SA23-2277-30
... appears to say otherwise:

No. Read what I actually wrote. The configuration information for an SMP4 or 
earlier environment is in multiple data sets, of which the CDS is only one. The 
CDS is the equivalent of a target zone, not of the entire CSI, and the manual 
you cited does not claim otherwise.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=Qtc7CRLhR62m9Vglr6iyfbkAN62o5ohE_t06AvB1jyg&s=_iP0gQfCrV5cvBwSr_aeLuT6mLZoVSd29bf9vk1_rng&e=


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 23, 2018 3:19 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

On Wed, 23 May 2018 18:55:21 +, Seymour J Metz wrote:

>The CDS may have been an equivalent to a target zone, but not to the entire 
>CSI. You won't get very far without a PTS and ACDS.
>
SMP/E for z/OS  IBM User's Guide SA23-2277-30 ... appears to say otherwise:

The consolidated software inventory (CSI)
The CSI data sets contain all the information SMP/E needs to
track the distribution and target libraries. As the card catalog
contains a card for each book in the library, the CSI contains
an entry for each element in its libraries. The CSI entries
contain the element name, type, history, how the element was
introduced into the system, and a pointer to the element in the
distribution and target libraries.*The*CSI*does*not*contain*the
*element*itself*, but rather a description of the element it
represents
[emphasis added]

This seems to use "CSI" to refer to the VSAM data sets, but not to PDSes that 
contain actual elements.

-- gil


--

Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.

[Longabaugh, Robert E]

You can do a LIST MOD(modname) XREF to find the load modules that a given 
module resides in.


Example:

SET BDY(CAIT0) .
LIST MOD(V37ALLOC) XREF .

Output shows that the module is in several load modules, none of which match 
the module name.

  NAME  



V37ALLOC  LASTUPD = RO97974  TYPE=UPD   

  LIBRARIES   = DISTLIB=ACTVMOD0

  FMID= CCTVC50 

  RMID= RO97974 

  LMOD= V37BTL00  V37BTL01  V37BTL02  V37BTL03  V37BTL04  
V37BTL05  V37BTL06  V37BTL07  V37BTL08
V37BTL09  V37BTL10  V37BTL11  V37BTL12  

  SYSMOD HISTORY  = SYSMOD   TYPE   DATE   MCS   -- 
STATUS --   
CCTVC50  FUNCTION  13.330  MODULEAPP

RO20699  PTF   13.330  MODULEAPP

RO44774  PTF   13.330  MODULEAPP

TR84363  APAR  15.265  MODULEAPP

RO84363  PTF   15.267  MODULEAPP

RO85335  PTF   15.323  MODULEAPP

RO97974  PTF   17.268  MODULEAPP


Doing the reverse and listing an LMOD will show the modules that it needs.  It 
does not show the physical presence of the modules, just the status in the CSI.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, May 24, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [SUSPECTED SPAM] smp/e question - PTF relinks, but missing CSECTs.



On Thu, 24 May 2018 13:35:06 -0500, John McKown wrote:

>I'm going to do a complete disk-level restore of the target system 
>(sandbox).

And the Global zone as well, I hope. Otherwise you will have a global out of 
sync with the target zone.

>I had a number Sx37 abends which may be the main problem.
>Perhaps resizing those libraries (after disk restoration) will solve 
>this problem.

Not likely, IMO.

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

RECEIVE ORDER from CA WAS(RE: Can the CSI info alone produce a final list required for full resolution of researched PTFs?)

[Longabaugh, Robert E]

We do offer RECEIVE order now for PTFs and holddata.  Here is information on 
getting started:  
https://support.ca.com/us/product-content/status/announcement-documents/2018/ca-smp-e-receive-order---maintenance-delivery-made-easy.html
 

Having said that, we are going have a brief period of limited availability this 
weekend for a hardware upgrade. 
https://support.ca.com/us/product-content/status/announcement-documents/2018/internet-service-retrieval-using-smp-e-receive-order-outage.html
 During this period, PTFs, APARs, and holddata will continue to be available on 
CA Support Online, which means MSM will be able to perform its acquisition task 
via Support Online.

We make both Error Holddata and FIXCAT Holddata available, plus HIPER and PRP 
source IDs, so if all of that is received into the CSI, REPORT MISSINGFIX would 
provide reliable information.

Bob Longabaugh
CA Technologies



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, March 15, 2018 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can the CSI info alone produce a final list required for full 
resolution of researched PTFs?

We run a nightly job for every CSI to pull all enhanced HoldData and PTFs for 
each IBM CSI so we will have both all closed PTF's and also any relevant 
Holddata/PE information. This means our CSI are as current as then can be when 
doing Apply Check/Applys (but doesn't stop anything going PE'd the next day)

For the 3rd Party software we would LOVE to be in the same position - CA is 
getting closer but not quite there yet.


Jerry Whitteridge
Delivery Manager - Safeway
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
03/15/2018 10:51:24 AM:

> From: Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/15/2018 10:51 AM
> Subject: Re: Can the CSI info alone produce a final list required for 
> full resolution of researched PTFs?
> Sent by: IBM Mainframe Discussion List 
>
> On Thu, 15 Mar 2018 12:30:10 -0500, Paul Gilmartin wrote:
>
> >Water is wet.  The sky is blue.  APPLY CHECK GROUPEXTEND reports only
the
> >information available to it.
>
> Right, but you asserted that "the information is in the CSI" for 
> "collecting all missing items that prevent resolution".
>
> --
> 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: ZOS 2.3 home page trying to find

[Longabaugh, Robert E]

CA z/OS Compatibility Matrix:  
https://support.ca.com/phpdocs/0/MSPSaccount/COMPAT/zos_compat.HTML

We also have a Mainframe Compatibility Matrix Page which links to the z/OS 
page, as well as DB2, IMS, CICS, IPv6, Pervasive Encryption, z/VM, and Z/VSE.
https://support.ca.com/us/mainframe-compatibilites/mainframe-compatibilities.html
 


Bob Longabaugh
CA Technologies



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Tuesday, January 30, 2018 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZOS 2.3 home page trying to find

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


On 2018-01-30 13:11, Jesse Lynch wrote:
> It looks to me like IBM changed things in regard to Home Page.   I used to 
> find one
> for ZOS 2.1.   And I cannot find one for 2.3.   In fact I go to my old one I 
> had for 2.1 and it
> is all different.   Not really useful to me.  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www-2D03.ibm.com_systems_z_os_zos_&d=DwICaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=cMNs-b4sGQJlDm9a39uqj8iE6wEsQzqp18HZPK7mMtY&s=xewzQqumbHw0r6U16gl4nXqcD3mlE7z1JnHgIy7NM1k&e=
>
> What I was actually looking for is the ZOS 2.3 ISV Compatability matrix.  
> Maybe it doesn't
> exist anymore.   I did find the 2.3 manuals, but am having trouble navigating 
> from above URL.
> Does anyone have any helpful urls?  TY.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www-2D03.ibm.com_systems_z_os_zos_features_software_isv230.html&d=DwICaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=cMNs-b4sGQJlDm9a39uqj8iE6wEsQzqp18HZPK7mMtY&s=Vy-gPYy-MFzy-XIaFvRzIBtmUmanxdvYywiIeT4xy68&e=

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__actionsoftware.com_support_&d=DwICaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=cMNs-b4sGQJlDm9a39uqj8iE6wEsQzqp18HZPK7mMtY&s=be69lP3Rxr4jLhVXpKUFxcV8c11fpEo7gErCwlH5oBs&e=

--
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: Removing Catalog Entries for Datasets That Do Not Exist [Public Information]

[Longabaugh, Robert E]

If you are not running DFHSM are you running any other product that could cause 
MIGRAT entries?   When CA Disk archives data sets, they are recataloged to 
MIGRAT with DEVT(C4C9E2D2).  In that case the catalog entry is legitimate.

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Usher, Darrold
Sent: Friday, August 18, 2017 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist [Public 
Information]

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Did your try DEL 'dsname' NSCR?

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

--
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: What to do with PTF dogies?

[Longabaugh, Robert E]

Maybe try a REPORT SOURCEID and see if any RSU show up.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, July 21, 2017 6:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What to do with PTF dogies?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


This may be at least in part a mechanical problem. Before I open an SR, I'd 
like to show one example. In our GLOBAL, UA74273 looks like this:

SOURCEID ALLAVAIL
 ORD00020
 PUT1410
 SMCCOR

No RSU assigned. However, SIS shows this:

RSU ...   1503

We routinely receive full HOLDDATA. I just did it again with 'get full.txt'. No 
entry for UA74273. Any obvious mistake on our part?

.
.
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 John Eells
Sent: Thursday, July 20, 2017 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What to do with PTF dogies?

Since I wound up in a meeting with someone on the CST team, I verified that 
everything is supposed to eventually be marked RSU, even PTFs for products that 
are not part of CST, based on age.  There are windowing factors make the delay 
between COR-close and RSU vary, but generally we would expect everything that 
was COR-closed by March to have been marked RSU by now.

The simplest way to see if something else is holding up your dogies (other than 
a lariat) is to run an APPLY CHECK with a SELECT list and see whether:

(a) they are actually not applicable to the zone for one reason or another; or,
(b) some PRE or IF chain is holding them up (e.g., due to a PE); or,
(c) they are not old enough to be summarily marked RSU by age; or,
(d) we somehow missed marking them RSU when they came of age.

If you think your dogies are in (d), please send me some examples and I'll 
forward to the team.  Maybe we need to "steer" something in the right direction.

Jesse 1 Robinson wrote:
> I have reviewed our current list of unapplied PTFs from LIST NOAPPLY(). The 
> real (unexplained) dogies are way fewer than I expected, fewer than I've seen 
> in the past. Maybe this has become a non-problem. I do want to make a point 
> that some folks may have missed. From the get-go, RSU was not merely a 
> relabeling of PTF bundling. PTFs included in an RSU have been tested 
> together, providing a new level of confidence over PUT, which was a temporal 
> packaging concept, not a functional one. With PUT, the chance of 
> incompatibility among PTFs is greater than with RSU.
>
> I agree that a small number of dogies should be taken to IBM for explanation.
>
> .
> .
> 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 Marchant
> Sent: Thursday, July 20, 2017 7:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What to do with PTF dogies?
>
> On Thu, 20 Jul 2017 09:57:31 -0400, Tom Conley wrote:
>
>> I'd ask the question "How come these PTF's aren't in an RSU?"
>> Shouldn't they have gone through CST at some point?
>
> I would think so too, unless they have been SUP'ed.
>
> --
> Tom Marchant
--
John Eells
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMPE Filter PTF list option based on date

[Longabaugh, Robert E]

LIST PTFS does not filter for the date.   The date is in the output, but 
several lines down from the PTF number, so you would have to save two lines per 
PTF, and the dates may fall outside the range.



As an alternative, you could use LIST LOG.  The post processing would be 
simpler. 
//SMPCSIDD   DISP=SHR,DSN=SMD.CCUWC50.DEV.CSI
//SMPLIST   DD   SYSOUT=*
//SMPCNTL   DD   *   
  SET  BDY(targetzone).  
  LIST LOG(01 30 17,02 02 17) .   /* start and end dates */

Then find all of the GIM22701I messages in the output.  Since the zone is set 
to the target, those would be PTFs that are applied.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Thursday, July 13, 2017 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE Filter PTF list option based on date

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Hello Group

Apologies if this is a repetitive question.

I am trying to understand if we can list the number PTF applied based on 
specific date range ?

We are at zOS 1.13

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

Re: Friday question: ISPF Statistics Manipulation

[Longabaugh, Robert E]

The 3.5 option has been able to manipulate member stats since I first saw "SPF" 
somewhere around 1980.   The most useful function I have found is being able to 
delete member statistics.  This is one way you can save a new member when the 
directory is out of space.  It is usually my second choice after trying "STATS 
OFF" on the new member I am editing.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, July 07, 2017 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday question: ISPF Statistics Manipulation

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


On Fri, Jul 7, 2017 at 8:05 AM, Barbara Nitz  wrote:

> A colleague of mine just asked me if ISPF statistics in a data set, 
> especially the USERID field, can be manipulated. We used ISPF 3.5 and 
> we were both astonished that I was easily able to fake a userid as the 
> one who last changed a member (testing in my own dataset, of course).
>
> This immediately raised the question for me if there is any RACF 
> control that would prevent this type of manipulation, especially since 
> the userids in those statistics are widely used as evidence. Does 
> anyone know if there are such RACF controls? A quick search in the 
> ISPF books didn't turn up any hint.
>

​There are no control possible for this. The ISPF statistics are simply data in 
the "user data area" portion of a member's directory entry.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.f54mc00_ispmc28.htm&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY&s=gmQ7AOx3yGz72ixAbnTxOfFf3gqZ-Z7ugt_coMfx1DM&e=

how a PDS directory entry is formatted:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.idad400_pdsd.htm&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=4Nkmg4zgV8bvaZuf3pzQfmzQUNagnQX66musH9Nq2lY&s=f80EEL_LypcCjkKc6P-Yiaqk55B20TIKjP7-qQsnRyo&e=

Binyamin mentioned ACF2, but a regular program can use the STOW macro to update 
a PDS directory entry. In fact, must be able to in order to add, delete, or 
update (other than "in place") a member. I doubt, that even ACF2 has any 
control to disallow updating the directory entry of a member in a DSN to which 
the user has update authority.


Bottom line: ISPF statistics are NOT ANY GOOD for any kind of security or 
auditing purposes. User can update them easily using 3.5 and you can't stop 
them. You would need a product such as PDSMAN 
https://docops.ca.com/ca-pdsman/7-7/en/administrating/what-is-pdsman


>
> Barbara
>
>

--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: Terminology - Datasets

[Longabaugh, Robert E]

It is two words at CA as well.

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Wednesday, April 26, 2017 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Terminology - Datasets

Skip wrote:
> Since the term 'data set' (is it one or two words?) is pretty much confined 
> to mainframe...

Since you asked: IBM created the term, and in IBM-land it's two words. I have 
an autocorrect set so I don't think about it most of the time.

--
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: Copy / Save screen text function in all TN3270 emulators?

[Longabaugh, Robert E]

QWS3270 (we are a customer, CA is not the vendor of this product)

Can highlight and copy: Yes
Save Screen to Text from a dropdown:Yes

Bob Longabaugh
CA Technologies 
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Wednesday, April 05, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Copy / Save screen text function in all TN3270 emulators?

Yes to both for Vista TN3270. 



.

.

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

Sent: Wednesday, April 05, 2017 8:43 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: (External):Re: Copy / Save screen text function in all TN3270 
emulators?



Tom Brennan Vista can do the copy but I do not know of save to file.



Charles





-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf

Sent: Wednesday, April 5, 2017 10:57 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Copy / Save screen text function in all TN3270 emulators?



I'm begging your indulgence to help with a little poll to understand which

TN3270 emulators have these two capabilities:



For example, here is mine:



Product:  x3270

- Can select screen text and copy to clipboard:  yes  (  /  )

- Has function to save screen as a text file:  yes  (File / Save screen text in 
file )



Your responses would be appreciated.



Kirk Wolf

Dovetailed Technologies

https://urldefense.proofpoint.com/v2/url?u=http-3A__dovetail.com&d=DwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=6kEhEp0jZT3aK905b1dlQTBiJMDpiWeLXKhVgS7skz4&s=_hsuTGbIAbKUTooF1lmTThbmk-4FxNDG870FJGavAvY&e=
 





--

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: Can SMPPTS datasets be consolidated?

[Longabaugh, Robert E]

Restore also does a reject if the options entry is set to "REJECT".

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Monday, March 20, 2017 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can SMPPTS datasets be consolidated?

On Mon, 20 Mar 2017 09:36:28 -0400, Kurt Quackenbush  wrote:

>> Kirt - if you are still listening:  Why oh why has "CLEANUP 
>> COMPRESS(ALL)" never been enhanced to include the SMPPTS or made an 
>> additional option?
>
>Mostly I think because the REJECT PURGE command with the COMPRESS 
>option provides essentially the same function I think you are asking 
>CLEANUP to provide.  That is, delete MCS entries from the SMPPTS data 
>sets and then compress those data sets.
>

Thanks for the explanation.  Normally I have no reason to run REJECT PURGE 
since I do purge at accept time.  For my z/OS zones I do have to do that 
because the 2 companies each have their own dlib zone to go along with the 2 
target zones, so I can't purge on accept. 

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mzelden.com_mvsutil.html&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=y5oDE0-qCY5zwbERo3GTHhtTzhLL6riW6CHUW01bH2A&s=vr_-_rlWwiEcn_tk_wV9KzH_X0EpeHwRyoKryLzDNio&e=
 

--
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: Fujitsu Mainframe Vs IBM mainframe

[Longabaugh, Robert E]

We still have some customers on the MSP version of CA Disk.  I'm not sure about 
VOS3. I remember the customer base being mostly in Japan and Asia, with some in 
Australia and one site in Spain.

Bob Longabaugh
CA Technologies
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vince Coen
Sent: Friday, February 24, 2017 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fujitsu Mainframe Vs IBM mainframe

Small correct for the info below :

The operating System George (1, 2, 3 & 4) run on ICL 1900 series, 2903 &
4 ( as George 2 & 3).
G1 was the original and was replaced with G2 - just as well as a bit of a dog 
but better than in native mode.

George 4 was for very big installations and was rarely used (compared to 
installs with G3) in my experience but acted like G3.

George 3 runs under emulation on Series 3900 (and the prior 2900 series) using 
DME only not VME which is a native O/S which was at least in the early days, 
written in Algol68R and yes I was just one of many programmers writing it !.
Later versions that fixed bugs and more importantly speeded it up written in S3 
while the compiler was improved.

Algol68R  - think a cross between C++ and C but more C.

As far as I remember (so might be wrong) Poland used ICL 1900 series built 
under license as the 2900 series was being build and sold in the UK along with 
the small systems 2903/4.  There was other small system that I was not involved 
with directly.

The 2903/4 was a microcoded system that ran G2 mostly but I know I did run 
OS360 Dos type o/s's on it by changing the microcode in the evenings and W/E's 
when I had a need but mostly for my own requirements (I was the DP Manger) 
although cannot remember why.
It took but minutes to change the microcode via mass storage device drive 
(dasd) or tape - can't remember which.

This all in the mid 70's.

Now the 30+ system still in use in the UK (other than the original painted 
Orange 2944 at Bletchley Park Computer Museum which is run at
weekends) actually run under emulation over Linux based Server/blade system or 
systems not sure which.

Yes I still have a complete manual set on CD (no engineering manuals) for the 
3900 range that was up to date - ish 7 years ago but software has not been 
updated since other than at best some bug fixes but knowing Fujitsu a little, 
that is unlikely.

At least they save on electricity as only use singe phase supply so can run one 
at home.
Would like to get one if going free - - -


Vince


On 24/02/17 15:47, R.S. wrote:
> W dniu 2017-02-24 o 15:14, Bernd Oppolzer pisze:
>> Am 24.02.2017 um 14:37 schrieb R.S.:
>>> W dniu 2017-02-23 o 20:09, Bill Woodger pisze:
 Also note that if you see a current job-ad for Fujitsu Mainframe 
 skills in the UK, it will be for an ICL Mainframe, running VME, and 
 being distinctly different from... anything from IBM. The COBOL is 
 to the 1974 Standard (with Extensions, including COMP-5 which 
 allows the definition of "bits").

 Various parts of "the government" have huge projects at the moment 
 converting their old ICL systems to Microfocus COBOL on "servers".
>>>
>>> It was very popular in Poland, because our government bought a 
>>> license for ICL machines and OS. Indeed, it wasn't even similar to 
>>> IBM family. The system name was GEORGE (GEORGE3), polish name of the 
>>> machine was ODRA (this is name of second largest polish river, which 
>>> crosesse Wrocław - a city where ODRA were built).
>>> I think the last ODRA's were in use approx. 10 years ago in a railways.
>>>
>>> Some years later there were also ODRA emulator working under VM on 
>>> IBM hardware. I met it approx 18-20 years ago. People claimed the 
>>> emulator was over 10 times faster than real machine. The emulator 
>>> ran on 6 MIPS 4381.
>>>
>>
>> There was a report generator on ODRA called TABU,
>> somehow similar to RPG, but more elegant IMO.
>>
>> I wrote a Pascal program for MPK Lodz (in 1991) to convert their
>> TABU reports to COBOL programs, because they replaced their
>> ODRA machine with a 4381 VM machine; but because they
>> had so much TABU reports, there had to be a solution for this.
>>
>> I also heard that the ODRA simulator was very successful;
>> MPK also sold computer time on ODRA to third parties, and
>> they charged for ODRA time, but in fact they ran the batch programs
>> on the VM based ODRA simulator, so they got more money in less time.
>>
>> There were also stories that they managed to build an interface for
>> a very large old Russian tape device and attach it to the 4381 somehow.
>>
>> BTW: the Odra river marks the frontier to Germany, too,
>> the German name is "Oder".
>
>
> Bernd,
> MPK is the installation I mentioned.
> (BTW: MPK is public transportation company, trams and buses)
> They replaced 4381 with P/390.
>
> And yes, Odra (Oder) is border river, upper part of it is also Czech.
>


-- 
- IMPORTANT –

This

Re: DIALOG PROCESSING ERROR

[Longabaugh, Robert E]

LISTDSI also has a reason code which is often very specific about the error.  
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjb800/ikjb800159.htm

If you don't see the &SYSREASON variable then rerun the dialog using ISPF 
option 7 and use breakpoints to help find it.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McCabe, Ron
Sent: Tuesday, January 24, 2017 6:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DIALOG PROCESSING ERROR

Hello IBM List,

I checked the archives for the problem I'm having with the dialogs and I 
couldn't see any replies to the same question I will be asking...so here goes.

I'm installing z/OS 2.2 using my 1.13 system as the driving system.  I'm up to 
the point where I have IPL'ed my 2.2 system successfully and now I am trying to 
get the dialog to work on it.  The dialog starts fine but when I choose the 
order I want to install I get the following error:

The dialog call shown in the ISPEXEC buffer issued a RETURN CODE of: 16 The 
contents of the ISPEXEC buffer was: /*0003*/LISTDSI SCPPEENU

Anyone else run into this problem?  What was the resolution?

Thanks,
Ron McCabe
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

--
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: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Longabaugh, Robert E]

A sysmod can have more than one ++VER.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 05, 2017 4:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

We’re drifting a bit here, but I had to look up ++VER to see whether a single 
PTF could be installed on more than base FMID. I find 

'-FMID--(--sysmod_id--)-'

I have never made peace with railroad track diagrams, but I think this means 
that only one base FMID can be specified. I don't see recursion. (Hate RR.)   

.
.
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 Marchant
Sent: Thursday, January 05, 2017 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
catastrophic error

On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:

>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone>
>COMPAREDTO(<2.2 zone>) and vice versa.

Is that going to give you any useful information, Art? I believe that it is 
possible to code the ++VER in a PTF so that the same PTF can be applied to two 
different FMIDs, but I can't remember ever seeing it.

Of course, I have been wrong before...

--
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: JES2 Changes in z/OS V2.2 - Presentation from 2015

[Longabaugh, Robert E]

$PJ2-1 was faster.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, December 07, 2016 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Changes in z/OS V2.2 - Presentation from 2015

On 6 December 2016 at 10:40, Lizette Koehler 
wrote:


>JES2 Growth: Grow from 400K to 1M Active jobs


It seems such a short time ago that job numbers had three digits... You could 
purge everything with $PJ1-999 .

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: Randomly disappearing IGD101I messages.

[Longabaugh, Robert E]

The IGD101I is in IBM code.  As long as the output volume is SMS controlled, 
the IGD101I should appear consistenly.

There are some ways that an SMS data set can become non-SMS after the move.  
This would depend on the ACS rules in place, or whether you are using an 
Allocation Management product like CA Allocate to redirect allocations, the 
TOVOL parameter which may have non-SMS target volumes, or if the SMS MC, DC, 
and SC of the original data was used by setting SMSALLOCY.   If that kind of a 
quick check does not produce the reason, then it would be best to open a case 
with Level 1 Support and they can look over the documentation.
 
IEF196I appears when a message is for a job running under the MSTR subsystem.  
This does not appear to be the case here.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, October 19, 2016 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

In my case we have automation suppressing the messages.

However, I will see them occasionally when it is preceded by an IEF196I message

IEF196I  IGD101I 


Our scheduling software reads the SMF Records as they are created.  It does not 
require the IGD101I messages to trigger the next job when a dataset/file is 
created/updated.

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Vernooij, Kees (ITOPT1) - KLM
> Sent: Wednesday, October 19, 2016 4:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> I am not looking for a workaround, we already have one.
> I am looking for the mysterious algorithm that decided to produce or 
> not produce IGD101I. This is what makes Control-M trigger a job.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Elardus Engelbrecht
> Sent: 19 October, 2016 12:44
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Randomly disappearing IGD101I messages.
> 
> Vernooij, Kees (ITOPT1) - KLM wrote:
> 
> >Well, the situation is becoming more and more curious:
> - I checked 400 runs of the job in the last year and IGD101I appears 
> in 2/3 of the jobs and does not appear in 1/3 of the jobs, without an 
> indication of why
> 
> Ok, try this temporary workaround:
> 
> In Control-M, insert JOBEND for the job which creates that dataset.
> Now trigger a job which checks whether the dataset is in fact there 
> (allocated / SMS / etc. ) [1] If true, trigger then your second job.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> [1] - Something like this little Clist:
> 
>   IF &SYSDSN('') = OK THEN   +
>DO
> WRITE DATASET FOUND
> SET &RC = 0
>END
>   ELSE  +
>DO
> WRITE DATA SET NOT FOUND
> SET &RC = 4
>END
> 

--
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: Randomly disappearing IGD101I messages.

[Longabaugh, Robert E]

When CA Disk moves SMS data sets, it renames the original to a temporary name 
and creates the new one with the existing name.  If the new data set is 
correctly created, cataloged, written, and closed, then CA Disk deletes the 
original (now renamed) data set.  If the move operation fails the original data 
set is renamed back to the original name.  The Auto Restore intercepts would 
not become involved, but the CA Disk SVC will intervene so that the last use 
date remains the same.

IGD101I is produced for a new SMS data set allocation.  IGD103I is for existing 
SMS data sets.  

Is it possible that the moved data set would sometimes be created non-SMS?  
This might be due to redirection by the ACS routine or an allocation management 
product such as CA Allocate.

Also check the CA Disk SYSPARM SMSALLOC, which determines if CA Disk passes the 
existing STORCLAS, DATACLAS, and MGMTCLAS to the allocation request for the 
move.  

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Tuesday, October 18, 2016 9:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

I would suggest asking CA about the DMS step not generating the IGD101I 
message.  (DMS has a "hook" in SMS, doesn't it?) 

Regards,
Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, October 18, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Randomly disappearing IGD101I messages.

One I see BMC has asked for doc. I would definitely do that.
Two, I concur with Tom Conley, Most scheduling software will provide an SMF 
Exit in order to see when datasets are created/updated.  

I would follow up with BMC and see what they say.  If they are dependent on 
IGD101I then you need to open a case to IBM on how or when the IGD101I is 
produced to SYSLOG.

A message is produced or not based on MPF list, Automation Tools, or a user 
exit.  The Vendors (IBM and BMC) should be able to help you determine why this 
is going on.

What z/OS Maintenance has been implemented when you first noticed this issue 
What BMC maintenance has been implemented when you first noticed this issue

What user exits are in your system (IEF*) or MPF List exit, or Automation tool 
changes.



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

CA Technologies LMP key at DR sites (WAS: serial numbers ... real and imagine)

[Longabaugh, Robert E]

Here are selected results from a search on "disaster recovery lmp site:ca.com". 
 These Knowledge Base articles should clarify that recovery can proceed without 
having the correct recovery site LMP key in advance of a disaster drill, or if 
the CPU serial is different than the one that the LMP key was generated for. 

These articles were written by different product groups but apply across the 
board since products call CA Common Services for LMP checking.

What will happen if I don't have valid LMPKEYs for my Disaster Recovery site?
http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec471961.aspx

How can LMP keys be obtained in an emergency?
http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec476815.aspx


Bob Longabaugh
CA Technologies 
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Wednesday, September 14, 2016 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine


Must of us have too many ethics to violate anything associated with M/F 
Licensing
 
Steve  
 
 
-Original Message-
From: "Dana Mitchell" 
Sent: Wednesday, September 14, 2016 2:55pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: serial numbers ... real and imagine



Falls under one of my favorite sayings:

Never ascribe to malice that which can be adequately explained by stupidity. 

Or the British version: cock-up before conspiracy

Dana


>On Wed, Sep 14, 2016 at 11:48 AM, Charles Mills  wrote:
>
>> Speaking as a vendor here -- and at the risk of flames -- it's not 
>> just "bad" customers. With the amount of outsourcing, turnover, 
>> overwork and layoffs of skilled people we were seeing a fair amount of 
>> "inadvertent"
>> license violation before we implemented the serial number check. 
>> Junior sysprogs or managers who just assumed they could install the 
>> software on another LPAR.
>>

--
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: IEBCOPY UNLOAD

[Longabaugh, Robert E]

True, CA Disk's PDS2SEQ proc won't export past member generations to the 
sequential file.  Sorry for not being clear about that.  Our 
Backup/Restore/Move support for PDSE V2 with MAXGENS is currently in 
development. 

The PDS2SEQ proc was originally developed to help with customizing your CA Disk 
proclib by writing it to a flat file, so you could do "change all" commands to 
customize the symbolics in the procs with your local values and then reload the 
proclib with IEBPTPCH.  My earlier reply was for a non-standard use and should 
be filed under "hints and tricks".   We did not plan on updating PDS2SEQ to 
preserve PDSEV2 generations because its primary purpose was to edit members 
which are newly delivered by CA that contain the CA defined defaults.

Also, yes TSO XMIT will preserve the ISPF stats of the unloaded members, and I 
have not experimented to see if it will preserve past generations of PDSE V2 
members. 

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, September 07, 2016 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBCOPY UNLOAD

If you are not using a PDSE with GENERATIONS for your MFSGENs, I would look at 
one of the two
1) TSO XMIT to a pds member - not source viewable, but can be download to PC 
and XMITMGR can be used to view the file.
2) IEBUPDTE and unload in IEBUPDTE format
  ./ ADD NAME=  control cards are built for you
3) IEBCOPY unloads to a Unload format.  You may want to look at the output.  
4) SAS UNLOAD a PDS.  Creates IEBUPDTE control cards around the members.

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Pinion
Sent: Wednesday, September 07, 2016 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

I have TERSED/UNTERSED PDS/PDSE's.  


Richard and Vickie Pinion

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Wednesday, September 07, 2016 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

Its only a flat file handler

Steve 

-Original Message-
From: "Richard Pinion" 
Sent: Wednesday, September 7, 2016 2:27pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

Don't have to use DF/DSS, TERSE will handle deflating and inflating a PDS/PDSE. 
 I don't know about PDSE member generations though.

Richard and Vickie Pinion


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, September 07, 2016 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

But be careful - CA-Disk does NOT support PDSE Member Generations at this time 
so if you're using them they will be lost and just like IEBCOPY there is no 
warning or notice - they are just ignored.

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service 
Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: Wednesday, September 07, 2016 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

If you have CA Disk you can use the PDS2SEQ proc to unload selected members or 
all members to a FB80 sequential file.  You can optionally imbed IEBPTPCH 
control statements which will help with reload.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Wednesday, September 07, 2016 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

There is another option but you may not like it.

You can use ADRDSSU and DUMP the file to disk and then TERSE that file before 
you FTP it

Steve  

-Original Message-
From: "Nims,Alva John (Al)" 
Sent: Wednesday, September 7, 2016 2:03pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

Doesn't TSO xmit also store ISPF stats, where IEBCOPY offload does not?

Here is another question: Does IEBCOPY offload work with PDSe's?  I believe 
xmit does.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, September 07, 2016 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

TSO Transmit actually can select individual members using the MEMBERS(xxx yyy) 
option

Re: [EXTERNAL] Re: IEBCOPY UNLOAD

[Longabaugh, Robert E]

If you have CA Disk you can use the PDS2SEQ proc to unload selected members or 
all members to a FB80 sequential file.  You can optionally imbed IEBPTPCH 
control statements which will help with reload.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve
Sent: Wednesday, September 07, 2016 1:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

There is another option but you may not like it.

You can use ADRDSSU and DUMP the file to disk and then TERSE that file before 
you FTP it

Steve  

-Original Message-
From: "Nims,Alva John (Al)" 
Sent: Wednesday, September 7, 2016 2:03pm
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

Doesn't TSO xmit also store ISPF stats, where IEBCOPY offload does not?

Here is another question: Does IEBCOPY offload work with PDSe's?  I believe 
xmit does.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, September 07, 2016 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEBCOPY UNLOAD

TSO Transmit actually can select individual members using the MEMBERS(xxx yyy) 
option

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service 
Delivery & Engineering


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, September 07, 2016 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEBCOPY UNLOAD

On Wed, 7 Sep 2016 17:04:28 +, Mosley, George wrote:
>
>I want to unload some PDS members (MFSGEN output, actually) into a single file 
>that I can keep in a PDS.
>
>I know that TSO XMIT does just that with the output file being PS/FB/80.
>
>When I execute IEBCOPY with SYSUT1 pointing to a PDS and SYSUT2 pointing to a 
>SEQ file (PS/FB/80), the DCB is altered to PS/VS/27936.
>
>What am I missing?
> 
That's what it does.  Sorry about your PDS.

I don't think TRANSMIT will select multiple members.  But you can IEBCOPY 
SELECTed members into a temporary PDS, and TRANSMIT that with INDD OUTDSN.
(And it'll fix your broken PDS.)

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


--
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: expiration date in a catalog entry

[Longabaugh, Robert E]

DASD data sets can have various retention periods (or expiration dates), either 
by SMS Data Class or JCL.  In CA Disk you can use the DSCL EXPIRE command to 
remove DASD data sets which are past their retention date.   

There is likely a  DFSMShsm (or maybe DFDMSdss) equivalent is for this, and 
also the same from other ISVs.  

Before the expiration date, if you attempt to delete the unexpired data set or 
write to it with DISP=OLD/SHR/MOD you will get a WTOR.  
IEC507D E addr,volser,jobname,stepname,dsname   
 IEC507D REPLY 'U'-USE OR 'M'-UNLOAD 
If you are in TSO updating that data set, your session is locked until the 
operator replies.

Non-SMS non-VSAM data sets do not show expiration in a LISTC, however that 
information is in the Format 1 DSCB.  SMS non-VSAM data sets do show the 
expiration date in the LISTC.

Bob Longabaugh
CA Technologies 
Storage Management 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, August 19, 2016 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: expiration date in a catalog entry

Only Forever is valid for DASD datasets, otherwise ignored.  Valid for Tape 
datasets.

On Thu, Aug 18, 2016 at 6:51 PM, Paul Schuster  wrote:
> At what point in time does the 'expiration date' of a data set get 
> written to its catalog entry?
>
> It seems you can allocate a data set with an EXPDT, but a subsequent 
> LISTCAT will show 'EXPIRATION--.000'.  There is a mention in 
> 'SYS1.MACLIB(IEFJFCBN)' that
>
> "
> NOTE: JFCBXPDT is not valid until the data set
>   is actually allocated."
>
> I run an IEBDG to add a record to the data set, (which will cause it 
> to be allocated), but a subsequent LISTCAT still shows the 
> 'EXPIRATION--.000'.
>
> But I have seen catalog entries that have an expiration date other 
> than .000, so when does this get updated?
>
> Thank you for any insight you can provide.
>
> Paul
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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 packaging question

[Longabaugh, Robert E]

What is the format of your JCLIN?  Binder or IEBCOPY?  The answer to that will 
determine the need for a relfile to contain the module you have to provide to 
get the new JCLIN to take effect.   

FILES(n) on the ++PTF statement means how many external files that SMP/E will 
need.  For PTFs, this should be zero.  JCLIN can be inline in the sysmod.  It 
does not have to be in a relfile. If the JCLIN is inline, then you code 
"++JCLIN" instead of "++JCLIN RELFILE(n)". If you have no relfiles, then there 
is no FILES(n) on the ++PTF.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, July 25, 2016 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E packaging question

On Mon, 25 Jul 2016 18:38:37 +, Way, Richard wrote:

>Or am I misunderstanding it even more basically, and my example will work, but 
>with FILES(1)? In other words, does the file count specifically exclude the 
>JCLIN? Or does it only exclude the JCLIN when the JCLIN is inline as opposed 
>to coming from a RELFILE?
>
Files() counts all the RELFILEs including JCLIN.  If you code FILES(0) it 
causes a syntax error -- you must entirely omit FILES().  (Grrr... Why?
It's a PITA when generating MCS with a program.)

If your PTF contains only JCLIN, APPLY will receive RC4, and as mentioned 
earlier, no modules will be relinked.  (Grrr PITA; worth RFE someday.)

Why deliver a PTF in RELFILE format rather than inline?  It proliferates TLIBs 
and inflates the catalog.

-- 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: SMP/E packaging question

[Longabaugh, Robert E]

To get SMP/E to relink the load module, which would be the trigger for adding 
the alias, you would have to provide one or more of the modules (defined by 
++MOD) that are contained in the load module.  

If you update the JCLIN without providing any elements, SMP/E does not relink 
the module at that time, but it does update the definition for the next time 
the load module does need to be relinked.  This information is available in the 
SMP/E Reference Guide under ++JCLIN.

Bob Longabaugh
CA Technologies


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Monday, July 25, 2016 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E packaging question

I need to provide SMP service to an existing released product to fix the binder 
control cards (only) due to some missing load module ALIASes. Can someone 
assist with identifying the steps we'd follow to accomplish this, please? I 
know what changes I want to make to the binder control cards, but I am not 
versed in SMP/E (obviously). I believe we'd just need to update the JCLIN and 
get them to RECEIVE/APPLY/ACCEPT the resultant PTF, but I am unclear on the 
details.

Thanks!

Rich Way
HPE Security - Data Security

--
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: Command to display Enqueue

[Longabaugh, Robert E]

There is a "WHOHAS" TSO command which is probably on CBT.  

Command:
  tso whohas 'sys1.proclib'


response is:

SYS1.PROCLIB 
 
JOB_NAME  SCOPESYS_NAME  TYPE  STATUS   JOBTYPE  ASID
   ------   
---   
TSOUSR1 System   SYSASHR Using   TSU   01B5
***  


Then you can decide whether to send a message to free the data set, or just to 
cancel the TSO session.
 





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, July 07, 2016 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Command to display Enqueue

On Thu, Jul 7, 2016 at 9:51 AM, FRISBIE, JIM  wrote:

> Is there a system command that will show if a specific file is enqueued?
> And even better, who holds the enqueue? We have a nightly batch job 
> that backs up a file on System-A and then restores it on System-B. 
> About once a month a TSO user (almost always the same Operator) will 
> have that file open, DFDSS can't get an exclusive enqueue and issues 
> RC=8. If it can be determined whether the file is in use before the 
> job is run, the Operator won't run the job and I won't get a phone 
> call at midnight. Even though the documentation says "Fill out a 
> Problem Report and DON"T CALL ANYBODY" the Operator persists in calling.
>
> My sleep and the life of the Operator are at risk, any help would be 
> greatly appreciated.
>

​I cheat. I put an IEFBR14 step at the end of the job with:

//ENQUEUE EXEC PGM=IEFBR14
//STOPIT DD DISP=SHR,DSN=dsn.to.reserve

I also put SHARE TOL(ENQF) in my DFDSS control cards if all I'm doing is a 
non-critical back up.




>
>
> Jim Frisbie
> Sr Systems Programmer
> 919-831-4711
>

--
"Pessimism is a admirable quality in an engineer. Pessimistic people check 
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then 
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

From "Star Nomad" by Lindsay Buroker:

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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Longabaugh, Robert E]

Rollover has been around for a while.   I have some "GDG wrap" tests from 2007. 
 At that time, GDGs defined in late 1979 with a new generation created each day 
would have been be reaching G.  

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Friday, May 27, 2016 5:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

Lizette Koehler wrote:
> Barry,
>
> I have heard that the number of GDGs may be allowed to go beyond 255 
> generations. Do you have any insight on this?  I am wondering how this 
> enhancement may impact the GDG Wrap condition.
>


GDGEs were introduced with z/OS V2.2 and can have up to 999
generations.* I believe both GDGs and GDGEs both "roll over" from
GV00 to GV00 these days without needing to be redefined, but I don't 
recall when we did that (other than it wasn't recently).  The number of 
concurrent generations is something you choose when you define either one.

* We were going for an even thousand until we weighed the value of "one more 
generation" against the cost of updating a bazillion messages to add space for 
another digit and decided 999 was close enough!

--
John Eells
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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What was a 3314? (was: Whither VIO)

[Longabaugh, Robert E]

Small track sizes were considered more efficient for VIO because of the number 
of page slots that had to be used in order to satisfy the allocation.  Also VIO 
would get all 16 extents at once, so saying TRK(1,1) was not better than saying 
TRK(16).  When a job did the VIO allocation, it got the page slots.  

In 1990 or 1991 (before I worked for Sterling Software and now CA) my employer 
had a series of system slowdowns which were caused by paging slot shortages, or 
exhaustion.  We found that many jobs were using VIO for SORTWKnn DDs.  This all 
traced back to an individual application programmer who knew just enough about 
VIO to see it was virtual, but did not grasp the difference between "virtual" 
and "unlimited".

I don't remember there being a way to put a hard limit on the total amount of 
VIO in use by the system. Now in the days of cached and solid state DASD the 
I/O performance payback isn't as big.  As in the previous response, the system 
did not set aside an entire 2314 (or 3330) worth of page slots to back the VIO 
requests.  It just fulfilled the requests for "tracks" as they came in.


Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, May 19, 2016 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


The whole disk is NOT in your virtual storage; The track window IS (IIRC).

Cheers, Martin

Sent from my iPad

> On 19 May 2016, at 21:45, Tony Harminc  wrote:
>
>> On 19 May 2016 at 01:44, Martin Packer  wrote:
>> It's sort of come back to me:
>>
>> A small track size limits the virtual storage window (probably 
>> usually below the line in 1989 when I looked at this). Or it might've 
>> been cylinder. But I think it was track.
>>
>> I'm wondering if anyone else remembers something like this.
>
> I'm not sure I get the "virtual storage window" idea. VIO emulates an 
> entire disk drive in virtual storage. So where is there a window? The 
> whole disk has to be in virtual storage at once. Well, I suppose there 
> could be logic to not allocate Virtual until used, but that would 
> surely better be left to VSM's and RSM's expertise at managaing their 
> respective kinds of storage.
>
> Now maybe VIO was changed much later (surely there wasn't expanded 
> storage in 1989...?) to use or perhaps favour expanded storage, in 
> which case a window model could make some sense. But only if VIO was 
> directly dealing with expanded storage rather than just requesting 
> that RSM use it to back virtual storage used to hold the VIO disk 
> data.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,  send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: Fwd: Tech News 1964

[Longabaugh, Robert E]

Largest might mean that whoever was taking the poll only wanted to check with 
100 places. A shoe maker may say how many NBA players wear their brand without 
checking the European or South American leagues, or NCAA or NBA D-league.  I 
suppose the top 100 does skew towards larger processors, so I assume that the 
other 4 are somewhere in the 90-100 rank. Maybe they are running VOS or MSP.

Bob Longabaugh
CA Technologies
Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, April 07, 2016 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Tech News 1964

W dniu 2016-04-07 o 21:37, Mike Schwab pisze:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.theregister.co
> .uk_2014_04_07_ibm-5Fs-5F360-5F50-5Fanniversary_&d=CwIGaQ&c=_hRq4mqlUm
> qpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lP
> xFUOMH-UM&m=sWJcNuOBhyK5cQhyJr0RmTLGpUWJOgJm_n2w7M1YWyE&s=jktmrXivOade
> NGnrXESeL9oHaKRjdtQWBycsJ_ec7Bw&e=
>
> 96 of the biggest 100 banks in the world still run IBM mainframes.
Keywords: still, largest.
"Stil" means defensive, marketshare loss.
"Largest" means only the largest institutions really need mainframe.
Questions: What about those remaining 4 biggest banks? What computers do they 
use?
Since those 4 bank in first 100 can live without mainframe, what about banks 
from third or fourth hundred?

Mainframe are usually used by big and OLD companies. "Old" is important here - 
it's IT legacy, it's cost of migration, etc.
What big and new (30 years old or less) companies use mainframe? Google? 
Facebook? Netflix?

> If there is job security in the world, that is it.
Not for me. Raincode.

--
Radoslaw Skorupka
Lodz, Poland






--Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.This e-mail 
may contain legally privileged information of the Bank and is intended solely 
for business use of the addressee. This e-mail may only be received by the 
addressee and may not be disclosed to any third parties. If you are not the 
intended addressee of this e-mail or the employee authorized to forward it to 
the addressee, be advised that any dissemination, copying, distribution or any 
other similar activity is legally prohibited and may be punishable. If you 
received this e-mail by mistake please advise the sender immediately by using 
the reply facility in your e-mail software and delete permanently this e-mail 
including any copies of it either printed or saved to hard drive.mBank S.A. z 
siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: 
kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy 
Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 
526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku 
S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
--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: rexx and tso alllocate

[Longabaugh, Robert E]

If you have CA Disk, there is a utility in the systems guide that lets you 
update the DSCB directly.  There also is still probably one in the CBT 
collection that runs as a TSO command.  Make sure to try it on test data first, 
and keep the access limited to systems people who need to use it.

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Tuesday, March 01, 2016 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: rexx and tso alllocate

On 03/01/2016 09:06 AM, Mike Schwab wrote:
> The LRECL should be at least the MAXIMUM record length.  Additional 
> space would be filler or trimmed by the actual length on a variable 
> record.
>
> On Tue, Mar 1, 2016 at 8:49 AM, Tim Brown  wrote:
>> Yes to  "So if you write X records and determine you need a different lrecl?"
>>
>> I will try your suggestions:  An IF Statement with a different ALLOC 
>> statement with REUSE or MOD might do it.  Or you may need to FREE and ALLOC 
>> as needed.
>>
>> Tim
One point which I'm not sure was made clear:  the attributes describing the 
DASD file in the VTOC are only set at OPEN-for-OUTPUT time, so changing the DCB 
after records have been written but before the CLOSE may affect current program 
behavior but those changes won't be reflected in the VTOC attributes for the 
file.  Subsequent allocation of the file without specifying LRECL will default 
at OPEN time to the  LRECL at the original OPEN.

A subsequent allocation of the file can specify a compatible desired LRECL and 
an OPEN for INPUT will use that LRECL to override the attributes from the VTOC 
on DASD, but again the values in the VTOC won't be affected.

To change the VTOC attributes after the original CLOSE, you must use a 
subsequent FREE and ALLOC specifying the desired LRECL and DISP(MOD) (to retain 
existing records) and then OPEN the file for output and CLOSE the
file.   As others have mentioned, if you set attributes this way to
values that are incompatible with some of the physical blocks already in the 
file, you will no longer be able to read those blocks successfully (and for a 
PDS file the attributes are for the entire PDS, so any file attribute change 
while writing one PDS member must be compatible with every member in the PDS).

The only reasons I can think of why you might want to reduce a VB LRECL to the 
minimum for actual records is
(1) to make clearer from the file definition itself whether the file would be 
compatible with some other program or process that has a documented upper limit 
for LRECL; (2)to make clearer from the file definition itself what minimum 
LRECL would be required if you wished to convert the file to RECFM=FB without 
any wasted space, or (3)possibly to aid a program wanting to use LRECL to 
dynamically pre-allocate storage before actually reading the records for 
manipulating a large number of records in memory without grossly 
over-allocating.

More commonly one would not define a VB file with an LRECL greater than 
actually needed unless the application using it was designed to potentially 
generate records of that length.  In that case  it is wiser to retain the 
designed LRECL even if current records are shorter, to make it clear that all 
downstream programs need to be able to handle that max LRECL. 

Except in the unlikely event that a poorly written program is internally using 
many max length moves to manipulate variable-length records, or erroneously 
padding records written into a VB file with useless trailing bytes, there is 
zero extra overhead in reading a RECFM=VB file whose LRECL is larger than 
actually needed by current data.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
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: Question about secondary maintenance companies

[Longabaugh, Robert E]

At Sterling Software Storage Management Division, we used SMS in Irvine, CA 
from around 1997-2001.   The only concern was that they didn't consider our 
work "production", even though that is where we created our distribution tapes. 
 Fortunately we were able to drive down there from San Bernardino and meet them 
in person.   After that, they were a lot more responsive.  Since they gave 
production priority, I don't think anyone besides another software development 
shop would have a similar experience.  

After Sterling Software was acquired by Computer Associates (as we were then 
named) in 2000, we migrated to the in-house data center.

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, February 04, 2016 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about secondary maintenance companies

On Thu, Feb 4, 2016 at 1:50 PM, Lopez, Sharon  wrote:

> Does anyone have any experiences (good or bad) with secondary 
> maintenance type companies that will support IBM mainframes?
>
> Thanks to everyone in advance.
>

​We've had a company called SMS for years. I've liked the employees and they 
are competent. ​The only machine that gives them any problems is our 3584, 
which we got pretty much the instant it was announced. This monster is used by 
both the z/OS system _and_ our LAN environment.

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sysmaint.com_&d=CwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=yEn4IoSYy7YmxauLkdmuVvsGFItKv3cR-Vp-8q5Wg_g&s=HSatsT0AKKugblLHjBdHllp5kzhLSmrzDbZqHopTq5w&e=
 

--
Werner Heisenberg is driving down the autobahn. A police officer pulls him 
over. The officer says, "Excuse me, sir, do you know how fast you were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing to a 
building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

He's about as useful as a wax frying pan.

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: So Long, and Thanks For All The Fish

[Longabaugh, Robert E]

Good Luck to you Shane


Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Thursday, December 31, 2015 3:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: So Long, and Thanks For All The Fish

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DN-5FdUmDBfp6k&d=CwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo&s=ldI_LXEDIHmJJS1V-vNMiGV9tPTxaHL7aHIORSCXuvI&e=
 



Shane,



Good luck in all your endeavors! 



I leave you with the following response:  
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DSJUhlRoBL8M&d=CwIGaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=o2gVjNZ9TdK6lLWT_C1wblxP02_yu_2JweU5e56_KLo&s=MlaQgklrm1EvKcYockXbax4dC9Edh9WpUzqaYbl7F-Q&e=
 



Bob



 



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane

Sent: Thursday, December 31, 2015 9:47 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: So Long, and Thanks For All The Fish



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: PTF error clarification

[Longabaugh, Robert E]

Receive the HOLDDATA.  Then SMP/E checks for PE.  Do specify GROUPEXTEND (or 
GEXT).

Bob Longabaugh
CA Technologies
Storage Management QA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, December 22, 2015 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PTF error clarification

In
,
on 12/22/2015
   at 05:32 PM, Jake Anderson  said:

>Does that mean, I have to receive the APAR

If there is a PTF that resolves the APAR, receive that. If not, and there is an 
APAR fix, receive that. Either way, specify group extend.
But first check for PE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
 We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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?

[Longabaugh, Robert E]

Good call on Fidelity, Steve.  When I was at the recruitment fair at UT Dallas 
for CA, Fidelity had the booth across from us and their banner specifically 
mentioned COBOL and JCL.

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, December 03, 2015 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?

Ah. Thanks - heading there.

On Thu, Dec 3, 2015 at 8:42 AM, Mark Pace  wrote:

> Mainline is still looking for Systems Engineers/Programmers.
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mainline.jobs_
> &d=CwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=_pjUpH7SxKBk
> B6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM&m=Z_MXjh3X0eTi2U1x6sJOSUtLkMR-usTX9m8Q
> n-Gal_E&s=znoIr6XNZ--eC6FS4aQ0-zIAk1b5po_fxh2-u03qimY&e=
>
> On Thu, Dec 3, 2015 at 8:46 AM, Huckert, James 
> 
> wrote:
>
> > AIG as well I believe.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Dover
> > Sent: Thursday, December 3, 2015 7:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: any shops hiring in DFW?
> >
> > John,  Fidelity is in Dallas, and I know they have a big mainframe 
> > presence.
> >
> > 
> > -- 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
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent 
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: any shops hiring in DFW?

[Longabaugh, Robert E]

Check ca.com/careers.  The facility is in Plano.

Good luck

Bob Longabaugh
CA Technologies
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Brown
Sent: Wednesday, December 02, 2015 6:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: any shops hiring in DFW?

Check Hudson Valley NY , opening available

Tim

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


**THIS IS AN EXTERNAL EMAIL**
 Do not open links or attachments unless you trust the sender and never provide 
USER ID or PASSWORD information.


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

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

Re: Fastest way to read OLDEST GDG entry

[Longabaugh, Robert E]

The Generation data set is in a deferred roll-in status when it is allocated.  
It becomes part of the rolled in generations during the deallocation phase.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

On Thu, 19 Nov 2015 15:59:37 +, J O Skip Robinson wrote:

>I haven't experimented with this, but going with NOSCRATCH is likely to 
>cause big problems with DASD GDGs. A data set residing on an 
>SMS-managed volume must be cataloged.

It has been a long time since I looked at this, but what I remember is that 
GDGs were a special case. For one thing, with SMS, a data set is cataloged at 
allocation time, not at step end like it was before.

One consequence of that is that is that a generation may be scratched as soon 
as the new one is allocated, rather than wait until the step ends successfully.

Consider a new GDG created with NEW,CATLG,DELETE. Before SMS, the old 
generation was scratched at the time the new one is cataloged at the end of the 
step, when the new one is cataloged.

As a result, the idea of a generation being rolled in and rolled out was 
created. The data set is cataloged, but is not cataloged as part of the GDG.

--
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: Self-service PC (was: "ageing mainframe")

[Longabaugh, Robert E]

.. and having to give the app permission to your location, contact list, 
photos, and call logs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, September 30, 2015 12:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Self-service PC (was: "ageing mainframe")

Agreed. I did an HR systems evaluation a few years back (why is a coder 
evaluating HR systems? Don't ask.) and all were big on "self-service," by which 
they meant if an employee, for example, wanted to know how many vacation days 
s/he had in the bank, s/he did not have to call HR, s/he just signed onto the 
HR system with a Web browser (and with "role-based authority" much lower than 
an HR person) and looked.

Today it would include logging in from a mobile device.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Wednesday, September 30, 2015 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Self-service PC (was: "ageing mainframe")

On 30/09/2015 10:20 PM, Paul Gilmartin wrote:
> On Wed, 30 Sep 2015 03:37:23 -0500, Shane Ginnane wrote:
>>> CentreLink is a 26,000 MIP customer
>>> http://www.techworld.com.au/article/303153/centrelink_ups_it_reform_keeps_model_204_legacy_/?pp=2.
>>> Phew, that's going to be a big blow for big blue when they move off.
>> Nope.
>> At that time (2009) Centrelink might (might ?) have been. It is now an 
>> amalgamation of Medibank and sundry others. Bigger and badder by large.
>>
> At the link I see the phrase "self-service PCs in offices."  How does that 
> work?
> What OS?  My understanding is that Windows is a one-man dog.

Today, in 2015, I think it means technologies like mobile where you can 
check-in at the airport using your phone. I book movie tickets on my phone and 
rock up at the cinema and just scan straight from my phone and pick up the 
tickets. No need for data input by a customer or operator. They want to do the 
same with welfare and medicare. There's already an app where you can scan a 
doctors bill and just ping it in without having to fill out forms or use a PC 
web based application which are also starting to look old hat. Everybody has 
mobile devices in their pockets and CIOs don't see mainframes as the platform 
of choice for the next generation systems which will ultimately reduce the cost 
of IT. Especially when IBM have got them over a barrel and can charge what they 
like because there is no competition.

--
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 limit tiny SMS-managed VSAM KSDS to one volume?

[Longabaugh, Robert E]

SMS VSAM is handled through Media Manager, so even if you bypass or shut down 
an allocation manager product, Media Manager consolidates the extents, which 
gets in the way of VSAM running out of space.  The easiest way to deal with 
this is to truly fill the volumes you are allocating to, with dummy data sets 
that either cause fragmentation or only leave a couple of tracks on the volume. 
 Where I work, we have a set of mini-disks of 15 cylinders to use for this 
purpose

Use the Guaranteed Space option to SMS so that you can direct the allocation to 
the specific  volume that you have pre-filled or fragmented.  

Bob Longabaugh
CA Technologies
Storage Management QA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Conley
Sent: Wednesday, September 30, 2015 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

On 9/30/2015 4:31 PM, Thomas Conley wrote:
> On 9/30/2015 12:25 PM, Farley, Peter x23353 wrote:
>> I need some advice from storage gurus.  I need to make a tiny 
>> SMS-managed VSAM KSDS that will NOT extend, neither to secondary 
>> space on the first volume nor to secondary volumes.  I need to test 
>> some error logic in an application program and I need a "file full" 
>> or "no more space" condition to test it.
>>
>> I have these parameters in the define cluster command:
>>
>> VOLUME(*) CYL (1 0)
>>
>> But when I try to fill up that file with IDCAMS REPRO so that there 
>> is no more room for any records by copying from a similar file with 
>> many records into the tiny one, it automatically extends to new 
>> volumes, with messages like this:
>>
>> SMS4000I TSOUSERZ, MKTSTFIL, SYS1, ATTEMPTING SPACVOLA FOR 
>> TSOUSER. TINY.DATA, XX, 1 SMS4400I VOLUME ADDED - OLD VOLUME 
>> XX, NEW VOLUME SMS . VOLUME COUNT IS 2
>>
>> I assume this is due to some hidden parameter in the STORCLAS that 
>> overrides my specification of only one candidate volume.
>>
>> My question is, how do I override that hidden STORCLAS parameter to 
>> force a no-more-space error here?  I deliberately want the attempt to 
>> add one more record to force an error.
>>
>> I do NOT have easy access to a storage admin on this system, so I 
>> need help from you.  ISMF is not available in my TSO menus, so I 
>> cannot check the STORCLAS for myself.
>>
>> TIA for any help you can offer.
>>
>
> Peter,
>
> Add a //ACCIGN DD DUMMY to your allocation and run JCL to bypass 
> ACC/SRS processing.
>
> Regards,
> Tom Conley
>

Oops, I saw earlier that these were ACC/SRS messages, but I see now that 
they're Stop X37 ProSMS messages.  In that case, try //PROIGN DD DUMMY or if 
that doesn't work //NOPLD DD DUMMY.

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: SMP/E Help

[Longabaugh, Robert E]

CALLLIBS are best used for modules not part of your product.  You would use 
NCAL and INCLUDE statements for libraries and modules supplied by your product 
or by another product or FMID from your company.

Using CALLLIBS does abdicate the control of any module not mentioned by an 
INCLUDE statement in the JCLIN.  I don't know of any LIST that would know the 
FMID of a module in your CALLLIB.  

You do not supply the other product's CSI to SMP/E, just the library name.  
This does not allow SMP/E to find the FMID or RMID information for those 
modules.  If your product uses a CALLLIB from a CA product, you could use the 
CAMODID TSO command to find that information in your loadlib.
For example: CAMODID DSN(your.loadlib) DETAIL [LMOD(lmodname)]

In addition to the LE modules mentioned by Tom, at CA we also use calllibs for 
Callable Systems Services and Cryptographic Services as well as IMS, CICS, and 
DB2.  Some products also bring in CA Common  Services modules through CALLLIBS. 
 You do not use INCLUDE statements for modules included by CALL processing.  

When these libraries are updated by the other vendor, your customers can run 
LINK LMODS to get the newer version of the modules from the CALLIBS linked into 
the modules from your product.  This is done at initial install, and also 
during PTF install, but must be done manually if you replace the CALLLIB from 
the other product.
 
NCAL processing is superior to CALLLIBS inside your product because SMP/E links 
the object from your ++MOD into every load module where it is defined.  If you 
simply replace ++MOD elements in your CALLLIB, they will sit there until the 
next LINK LMODS is run.  The new CALLLIB modules will also be called into a 
relink for LMODs which are affected by PTFs within your products, but it takes 
manual action, meaning ACTION holds in your PTFs, which is an interruption to 
the maintenance flow.

Bob Longabaugh
CA Technologies
Quality Assurance

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, September 15, 2015 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help

On Mon, 14 Sep 2015 11:24:31 -0500, Paul Gilmartin wrote:

>On Mon, 14 Sep 2015 09:41:54 -0500, Tom Marchant wrote:
>>
>>CALLLIBS processing can be confusing at first, too
>> 
>Never used CALLLIBS.  I need to RTFM.  I believe autocall abdicates 
>control of load module content.  Will any SMP/E LIST option show 
>specific versions
>(RMIDs) of objects included from CALLLIBS?

I would not even consider using CALLLIBS to include elements that are part of 
the product. CALLLIBS is useful when modules are required that are not part of 
the product. For example, if LE modules are required.

--
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: SMP/E Help

[Longabaugh, Robert E]

The "Standard Packaging Rules for z/OS-Based Products" document was in the 
SMP/E 3.5 documentation set, which was contained in either the z/OS 1.11 or 
1.10 bookshelves.  There is another recent IBM Main thread on older 
documentation which will help you find the older z/OS docs.  Even though it has 
not been updated lately, it is a good reference for things like relationships 
between base and dependent Function Sysmods and how to build load modules 
either with NCAL or CALLLIBS.

Most of the rest of what you need to know is in the SMP/E Reference Guide, 
which is current.
- syntax of all the MCS statements
- documentation of GIMZIP in Chapter 11 "Service Routines"
- naming conventions
- registering your component IDs and element prefixes with IBM

You will also have to start thinking about maintenance delivery and building 
PTFs and APARs.

Bob Longabaugh
CA Technologies
Storage Management QA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, September 11, 2015 9:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help

Hey Kurt, how about some documentation that is NOT outdated? What is a vendor 
with a new-to-SMP/E staff and product supposed to do?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Friday, September 11, 2015 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Help

> I need some help with SMP/E. I need to convert our software to use SMP/E.

> I need a how to build a complete package and then how do I install it. 
> I want to use GIMZIP, I think this should work.

To clarify, "packaging" into SYSMOD format so that you can use SMP/E RECEIVE, 
APPLY, ACCEPT to install your software is independent of using GIMZIP.  GIMZIP 
is a means to create a portable format of your stuff, whether that stuff is in 
SYSMOD format or just a bunch of data sets.

If your goal is to support using APPLY for the install, then I suggest you 
concentrate on creating SYSMOD format first (writing MCS, creating RELFILE data 
sets, JCLIN if necessary).  Then you can use GIMZIP to make the SYSMOD format 
stuff portable for delivery over the internet, as opposed to worrying about 
physical media (tape).

> Does anyone have any suggests or places they can point me to ??

The already mentioned "Standard Packaging Rules for z/OS-based Products" 
(SC23-3695-10) should help you with creating SYSMOD format.  Also as already 
mentioned, this book is outdated and does not address the second part, which is 
using GIMZIP to make your SYSMODs portable for internet delivery.  However, 
that should be relatively straight forward after you achieve SYSMOD format.

--
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 comes SDSF HOLD panel shows one line per OutputGroup instead of per job?

[Longabaugh, Robert E]

The multiple output groups are caused when you do a SET BOUNDARY within a step. 
 If you use a different step for each SET BOUNDARY, then a single output entry 
appears for the job.  

Bob Longabaugh
CA Technologies


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Monday, July 27, 2015 6:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: How comes SDSF HOLD panel shows one line per OutputGroup 
instead of per job?

Solved! It was SMP/E who fooled me. I'm sorry to not have recognized this 
before posting.
I had an SMP/E job doing some LIST processing for one zone. All DDs except from 
the CSI were dynamically allocated. I repeated the LIST statement in the same 
step to list from some more zones. SMP/E allocated and deallocated for each 
LIST, which lead to a set of new output groups each time (SMPLOG, RPT, LIST, 
OUT).

I never seem to have done this before, or, my memory is failing

 --
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: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL

[Longabaugh, Robert E]

LISTDSI will return either a 0, 4, or 16. It also sets one of a few dozen 
reason codes, which indicate whether the data set is cataloged, migrated, if 
the directory is readable, or several other useful pieces of information.  This 
is why the request takes more time than simply reading a VTOC entry.   One way 
to reduce overhead is to supply the volume.  In that case, LISTDSI uses an 
allocate instead of catalog locate.

Going through the reason codes, it indicates RC=12 means VSAM is not supported. 
 That may reduce the usefulness of LISTDSI in gathering space statistics. 

LISTDSI Return Codes: 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm
LISTDSI Reason Codes: 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm

Bob Longabaugh
CA Technologies
Storage Management QA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Friday, July 17, 2015 8:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI 
'FULLY.QUAL.DATASET.NAME' NORECALL

DCOLLECT  + program or Rexx... ?


I am processing a list of datasetnames and want to calculate the amount of 
space used for ONLY those files which are not MIGRATED.
The program currently uses
 R = LISTDSI ("'"FQSN'"')  where FQSN is the Fully Qualified Dataset Name 
Because there is no NORECALL parameter, each file gets RECALLED before 
continuing.  The overhead is terrible. LISTDSI will return "dataset is 
migrated" if NORECALL is specified and the dataset is currently Migrated.


--
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: FTP to USS directory

[Longabaugh, Robert E]

The CAUNZIP utility uses a capability from CA Common Services.  The required 
level to use that capability is
"CA Common Services Version 14.0 with PTF RO54887 or CA Common Services Release 
14.1 with PTF RO54635 and RO58216 applied"

If Common Services is at this level, then CAUNZIP should work correctly.

The alternate to using CAUNZIP would be to unzip on your PC and then send each 
file to the mainframe via the FTP commands which Eileen Barkow gave an example 
of earlier.

You could also try IND$FILE to transfer the unzipped file from a PC to z/OS.  
When I had Attachmate as the 3270 emulator, it was fairly easy to get the 
IND$FILE commands to take the individual PC binary files and write them to a 
sequential SMPPTFIN file on the mainframe.  For other emulators, the FTP 
transfer may be easier.   

If none of those fit your needs, it may help to contact CA Technical Support 
for the product you are updating.

Bob Longabaugh
CA Technologies
Storage Management QA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zos reader
Sent: Tuesday, April 21, 2015 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

The Video is awesome. Thanks All for your help..

Is there any other alternate way to Transfer the scartX,zip file directly to 
Mainframe PDS member and apply the CAR2014 for CA1 instead of transferring to 
USS directory and then unzip the file and apply the CAR.

I'm facing a problem with CAUNZIP utiity to unzip the scartX.zip file and thats 
stopping all CA CAR maintanenece for all PRODS.

Kindly guide me to move forward.

Thanks,
Samat

On Fri, Apr 17, 2015 at 1:21 AM, Scott Barry  wrote:

> The PAX ESD Guide on SUPPORT.CA.COM (CA SUPPORT ONLINE), Downloads 
> site is quite lean with the FTP example, presuming the reader has 
> sufficient knowledge / experience with retrieving to USS directly, as 
> compared to traditional MVS dataset retrieval.  As well, some of the 
> other "Download Help" references / links there are minimally helpful 
> or non-existent (...check back often...  as I recall seeing)
>
> Scott Barry
> SBBWorks, Inc.
>
> --
> 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: FTP to USS directory

[Longabaugh, Robert E]

Here is a video which includes downloading a product from CA Support Online 
directly to z/OS.  The z/OS download starts at about 4:50 and ends at 6:56. The 
first download example is TSO prompt and then a batch download example is given.

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec491839.aspx
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longabaugh, Robert E
Sent: Thursday, April 16, 2015 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

Yes, you can download directly to your z/OS system. 

When you are in the Download Cart area of CA Support Online, you can select 
either "Preferred FTP" or "Alternate FTP".  
Support Online then displays some FTP commands which you can cut and paste into 
your FTP JCL.  It basically signs you into the FTP server, takes you to the 
directory for your order, and issues a GET command.

//FTP   EXEC PGM=FTP   get the pax from CSO  
//SYSTSPRT  DD   SYSOUT=*
//SYSPRINT  DD   SYSOUT=*
//SYSUDUMP  DD   SYSOUT=*
//OUTPUTDD   SYSOUT=*
//INPUT DD   *   
scftpd.ca.com
anonymous use...@yoursite.com
cd /ftp/orders/99/12345678   
binary   
get C5XGF00.pax.Z /a/yourdirectory/C5XGF00.pax.Z << this PAX is CA 
Allocate
quit 
// 

The line with "cd" takes you to the directory on our server.  Use whatever 
Support Online generates for you.
In the line with "get", the first "C5XGF00.pax.Z" is the name on our 
server, so don't change that.  The "/a/yourdirectory/" is information that 
exists at your site and you will need to change it to something that exists on 
your z/OS system.

If I have time to look later, and I remember to do this, I will try to find a 
link to a good explanation of all of this on CA Support Online, especially if 
it shows you what Support Online displays for the FTP commands.


Bob Longabaugh
CA Technologies
Quality Assurance, Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Wednesday, April 15, 2015 9:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

Thanks Paul & Eileen, it worked I have transferred the pax files.

Lizette, we are not using it in our shop, we will try to implement in near 
future.

Thanks All..!!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, April 16, 2015 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

On 2015-04-15 09:32, zos reader wrote:
> Good morning All..!!
> 
> I have more number of PTF's to be applied for CA common services.
> Initiallyi downloaded CAR2014 in zip file format and i was not able to 
> UNZIP using CAUNZIP utility due to missing PTF's.
>
What zip files did you get, and how many?

Can you download directly to z/OS?

On the PC (if you have nothing better than Windows):

ftp ZOS
cd /unix/directory
binary
put file1.zip
put file2.zip
...
put filen.zip
close

Then use the "jar" command to unzip them.

> Also CAUNZIP utility is not supporting and for that too i need to 
> apply few more PTF's.
> Now I have downloaded the the PTF's in PAX.Z format in my PC and i 
> need to transfer as bin to USS directory.
> Can anyone please help me out with the jcl or  process for 
> transferring from PC to USS directory or anyother way for FTP'ing
> 
Again, use the process above.  There may be many PAX.Z files.
you may need to use the mkdir command to create intermediate level directories. 
 This is all easier with the z/OS UNIX shell.  In JCL, you can use the BPXBATCH 
program to issue shell commands.

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

Re: FTP to USS directory

[Longabaugh, Robert E]

Yes, you can download directly to your z/OS system. 

When you are in the Download Cart area of CA Support Online, you can select 
either "Preferred FTP" or "Alternate FTP".  
Support Online then displays some FTP commands which you can cut and paste into 
your FTP JCL.  It basically signs you into the FTP server, takes you to the 
directory for your order, and issues a GET command.

//FTP   EXEC PGM=FTP   get the pax from CSO  
//SYSTSPRT  DD   SYSOUT=*
//SYSPRINT  DD   SYSOUT=*
//SYSUDUMP  DD   SYSOUT=*
//OUTPUTDD   SYSOUT=*
//INPUT DD   *   
scftpd.ca.com
anonymous use...@yoursite.com
cd /ftp/orders/99/12345678   
binary   
get C5XGF00.pax.Z /a/yourdirectory/C5XGF00.pax.Z << this PAX is CA 
Allocate
quit 
// 

The line with "cd" takes you to the directory on our server.  Use whatever 
Support Online generates for you.
In the line with "get", the first "C5XGF00.pax.Z" is the name on our 
server, so don't change that.  The "/a/yourdirectory/" is information that 
exists at your site and you will need to change it to something that exists on 
your z/OS system.

If I have time to look later, and I remember to do this, I will try to find a 
link to a good explanation of all of this on CA Support Online, especially if 
it shows you what Support Online displays for the FTP commands.


Bob Longabaugh
CA Technologies
Quality Assurance, Storage Management


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Wednesday, April 15, 2015 9:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

Thanks Paul & Eileen, it worked I have transferred the pax files.

Lizette, we are not using it in our shop, we will try to implement in near 
future.

Thanks All..!!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, April 16, 2015 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP to USS directory

On 2015-04-15 09:32, zos reader wrote:
> Good morning All..!!
> 
> I have more number of PTF's to be applied for CA common services.
> Initiallyi downloaded CAR2014 in zip file format and i was not able to 
> UNZIP using CAUNZIP utility due to missing PTF's.
>
What zip files did you get, and how many?

Can you download directly to z/OS?

On the PC (if you have nothing better than Windows):

ftp ZOS
cd /unix/directory
binary
put file1.zip
put file2.zip
...
put filen.zip
close

Then use the "jar" command to unzip them.

> Also CAUNZIP utility is not supporting and for that too i need to 
> apply few more PTF's.
> Now I have downloaded the the PTF's in PAX.Z format in my PC and i 
> need to transfer as bin to USS directory.
> Can anyone please help me out with the jcl or  process for 
> transferring from PC to USS directory or anyother way for FTP'ing
> 
Again, use the process above.  There may be many PAX.Z files.
you may need to use the mkdir command to create intermediate level directories. 
 This is all easier with the z/OS UNIX shell.  In JCL, you can use the BPXBATCH 
program to issue shell commands.

-- 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: Anthem Healthcare Hacked

[Longabaugh, Robert E]

In the late 1980s when I was working for a landline company in the Midwest, we 
ordered some used 3380s.  The previous owner had not cleaned their data from 
the volumes. After determining it wasn't our data, we initialized the volumes 
and started using them, but that data did escape the control of the previous 
owner.

Bob Longabaugh
Quality Assurance
CA Technologies Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, February 06, 2015 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anthem Healthcare Hacked

I'll be honest.  I do not understand the need for encryption at the disk 
hardware control unit level.  I get it for tape, if tape is being transported, 
or handled by humans.  Seems like that would *only* protect data if the DASD 
box was being transported somewhere, or you threw the old disks away with data 
still on them.   Any of those situations are clearly remediated by good 
procedures.  Any access from within the datacenter is going give you 
unencrypted data, right?   What is needed is dataset/file/record level 
encryption so that certain data can only be decrypted with the correct 
credentials.   That may or may not have avoided the problem at Anthem, 
depending on the ID they were able to steal.   

I am one of those affected by this breach.  I know the news is reporting that 
the database had 84Million subscribers data in it, but they are still 
ascertaining what data was actually read.   But as one of the news media 
reported, 84M is almost 1/3 of the US population.   I suspect we are going to 
see changes in the health care industry(and others) similar to what PCI did for 
financial institutions.   The data stolen is much more damaging than bank 
accounts.  Bank accounts can be closed/changed, etc.   This will haunt me, and 
family for life.
_
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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, February 06, 2015 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anthem Healthcare Hacked

On 6 February 2015 at 14:22, Tom Brennan  wrote:
> Maybe someone can tell me what difference it makes whether the data 
> was encrypted on disk or not (as some news reports are talking about).
> I mean, if I do a SELECT * from an admin id I must be going through 
> the decrypt process, right?  So it makes little difference if the 
> source data is encrypted I would think.

It depends on how the data is leaked, or "exfiltrated" to use a word we've 
heard rather too much of lately. If it's through the intended app or user 
interface to which the attacker has obtained credentials, then yes, it's 
probably all nicely decrypted and ready to go. But presumably any such app has 
controls on who can look at what data, and probably who -- even if authorized 
-- can look at how *much* data.
Otoh, if the data is leaked from e.g. a backup file or captured in transit, 
then encryption will probably keep it from being useful.

Tony H.

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

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

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

Re: Any standard IBM tool to set ISPF statistics in a batch step?

[Longabaugh, Robert E]

Also you can use LMMSTATS from REXX or other languages.   The command is 
documented in TSO/E REXX Reference.

"ISPEXEC LMMSTATS DATAID("data1") MEMBER("mbrname")" " USER("id_of_usr")"   
   

Bob Longabaugh
Quality Assurance Architect
CA Technologies
Storage Management 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Tuesday, September 30, 2014 2:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step?

To further my contribution to this discussion, I was looking for a way to run 
the ISPF opt 3.5 in batch last year, when I was working as a contractor to IBM, 
but never did figure out the way to do so.  Gee, they give us a way to SuperC 
Compare (3.12) in batch, why can't IBM give us 3.5!  :)

Now I know you asked for "Any standard IBM tool", but if you don't mind, 
there are a couple of tools on the CBTTAPE (www.cbttape.org) that you might 
want to take a look into;

File 357 has "TOUCH" a PL/I based program to modify ISPF Statistics.
File 720 has "COPYISPF" which copies from one PDS to another while updating the 
ISPF Stats in the process.  This is not exactly what you want, the author 
writes out some fixed information, but you might be able to modify to use 
current date/time information during the copy process.

Just trying to be helpful.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, September 30, 2014 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step?

That explains the behavior I saw, though it does not excuse it.  My tests used 
LRECL=1028.  Why in the world does LRECL have anything at all to do with 
whether ISPF statistics are recorded or not?  That just makes no sense to me 
whatsoever.

Thank you for the RTFM pointer.

Another sad fact is that when the z/OS FTP server does set the ISPF statistics, 
it seems to use a simple-minded STCK + STCKCONV algorithm, since in my tests 
the date and time are set to UTC instead of setting them to the local time 
using the CVT time zone values.  It makes the ISPFSTATS option a lot less 
useful, IMHO.  There ought to exist another SITE option to change that behavior 
when the receiving z/OS system is known a priori to be using UTC time in the 
hardware clock.  I would suggest ISPFSTATS[=UTC|LOCAL] if I could, where 
"LOCAL" means use the CVT values to adjust the STCK time before STCKCONV.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Tuesday, September 30, 2014 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step?

For your VB data set, is the LRECL less than 256 (e.g.: 255 or less?).  From 
"IP User's Guide and Commands v1.13 (SC31-8780-11)" it states on page 98:

Note: ISPFStats is ignored for sequential data sets. Also, the record format 
must be either variable or fixed, and the record length must be less than 256.
---
Transferring PDS member to PDS member in block mode or in compress mode differs 
in behavior from transferring in stream mode. If the user wants to preserve the 
statistics of a PDS member that already has the statistics and have the same 
statistics copied over to the target PDS member, transferring in block mode or 
in compress mode is required.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, September 30, 2014 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Any standard IBM tool to set ISPF statistics in a batch step?

On Tue, 30 Sep 2014 11:54:54 -0400, Farley, Peter x23353 wrote:
>
>The motivation for this is the sad fact that the IBM FTP server does not set 
>statistics for RECFM=VB PDS/E members even when the SITE ISPFSTATS toggle is 
>set.  It only does it for RECFM=FB PDS/E members, even at the z/OS V2.1 level.
> 
WTF!?  And why?  I hadn't noticed that.  Is it because it's easier to count 
lines if RECFM=FB (count bytes and divide by LRECL)?  Or because revision level 
is/isn't available as the last two characters of the sequence numbers 
(shouldn't matter).  Is this documented?

Does NFS have the same behavior?  I'll need to test.  I know that "touch" via 
NFS fails to update the time stamp.  Can the programmer enable/disable stats 
with NFS?

If the data originate from a z/OS (or CMS) system, it might be better to use 
TRANSMIT (SENDFILE)/RECEIVE.  If you want to copy to/from a UNIX (e

Re: CA-DISK (DMS) QUESTION

[Longabaugh, Robert E]

The command that was specified:  LISTD 
DSN=SYS2.VPRIM.GPRODT.DMSN.C2014204.T024542 will check for archive and backups 
of the data set SYS2.VPRIM.GPRODT.DMSN.C2014204.T024542, but not for the 
archived data sets written inside it.

Normally you would see something like LISTD DSN=SYS1./ to see backups of 
SYS1.LINKLIB.

If you use the LISTV command link this, it will show the generated archive key. 
  
LISTV DSN=SYS2.VPRIM.GPRODT.DMSN.C2014204.T024542

The output will show you the archive key on the left, in this case it is 
#98RQJ.   
ARCHIVWRITTEN  DATA 
 BLOCK   K/M
 KEY   DATA SET NAMETIME   DATE   EXPDATE  SETS  COUNTBY
--  -  --- - ---
#98RQJ QDMSTEST.ARC0.DMSC.D2014203. 2126 2014.203 1999.000   1 1  25
 ---

Then you can use the key to use the LISTD command to see the contents of that 
ARCHVOL

LISTD VOL=#98RQJ


You can change the order of characters in your SYSPARMS member if you want, 
using the ARCVOLID entry
ARCVOLID#$+-%&¢@.  We did that on our QA system which is why the example shows 
the # instead of @ as the first character.

Bob Longabaugh
CA Technologies
Quality Assurance Architect - Storage Management
San Bernardino, CA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Craig Pace
Sent: Wednesday, July 23, 2014 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CA-DISK (DMS) QUESTION

Yes you can.  All DISK (ML1) archives/backups are written with a key starting 
with @.  So, if you know the key, can you use that are if you wish to see all 
you can use the LISTD keyword with DSN=@/.

If you are just wanting to see details of the true file, you use the LISTD 
procedure with the LISTF keyword.

I hope this helps.


One Fruit of the Loom Drive
PO Box 90015
Bowling Green, KY 42102-9015

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, July 23, 2014 12:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CA-DISK (DMS) QUESTION

I find that the folks at CA Support very helpful. Or you could go to the MYCA 
community forum for CA DISK and get quick responses there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Dawes
> Sent: Wednesday, July 23, 2014 6:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CA-DISK (DMS) QUESTION
>
> G'Day,
>
> Is there a way of knowing the contents of an archived tape which is written 
> to disk?
> I tried the LISTD which works for an archive tape dsn.  I tried the 
> same by doing the following :
>
> LISTD DSN=SYS2.VPRIM.GPRODT.DMSN.C2014204.T024542
>
> I got the following message :
> ADSDM484 3543 NO RECORDS SELECTED
> ADSDM484 3544 RECORD NOT FOUND FOR =
> SYS2.VPRIM.GPRODT.DMSN.C2014204.T024542
>
> Could someone suggest how I could read the contents of an archive tape 
> which is written to dasd instead of tape?
>
> Thanks in advance for your support and help.
>
>

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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



--
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 Question regarding automatically relinking a load module with maintenance

[Longabaugh, Robert E]

I have worked in QA for CA Technologies (Sterling Software prior to 2000) for 
20+ years.  In the course of doing my job I need to receive, apply, restore, 
and reject PTFs multiple times a week.

There isn't any shortcut to the REJECT that would actually save time.  The CSI 
is key to SMP/E tracking.  If one of the libraries controlled by that CSI is 
altered or restored, SMP/E becomes inaccurate. That alone would waste more of 
someone's time than just about anything else.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 16, 2014 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Question regarding automatically relinking a load module 
with maintenance

On Thu, 15 May 2014 14:40:11 -0500, Tom Marchant wrote:
>
>>I have observed that merely deleting from the SMPPTS and re-RECEIVEing 
>>leaves tramp entries in the GLOBAL zone.
>
>I'm not surprised. Do it correctly. I wouldn't be surprised if Kurt Q. 
>knows how to clean it up correctly without using REJECT, but I would be 
>surprised if he bothers. I know that I don't know how to do it 
>correctly.
>  
In fact, it was Kurt who alerted me this behavior here several years ago.  It's 
documented.  I don't know if he was making a recommendation or merely stating a 
fact, caveat emptor.

You can clean up almost anything with UCLIN, but would you want to make it a 
habit?

-- 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: SOURCEID (again)

[Longabaugh, Robert E]

There was toleration support in SMP/E 3.4 for FIXCAT holddata, but it was to 
ignore it, not to process it.  Note that GIM58903W does not show up in QuickRef 
until SMP/E 3.5.  I don't recall the PTF# for toleration.  It was in the 2008 
timeframe.

You also may need to run the upgrade command in order use newer features of 
SMP/E like FIXCAT or the improved load module processing from several years ago.

Increasing PEMAX can have unintended results.  The default is 32767, but the 
highest value that can be specified via UCLIN is .

Bob Longabaugh
CA Technologies
Storage Management
San Bernardino, CA

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, February 21, 2014 3:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SOURCEID (again)

In:

http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim3000/gim3161.htm

I read:

Coexistence considerations

SMP/E for z/OS User's Guide
SA23-2277-00

SMP/E releases before V3R5 cannot process the MCS input that is developed 
specifically for V3R5, nor can they process data in the SMPCSI data set.
In SMP/E V3R4, if your SOURCEID value meets either of the following conditions, 
a message is shown to indicate that your operand contains a value that cannot 
be processed by the current release of SMP/E:

Your SOURCEID value is 9 to 64 characters in length.
Your SOURCEID value contains a character other than uppercase alphabetic 
(A-Z), numeric (0-9), or national (@,#,$).

Is the message mentioned GIM58903W?  If not, which?  (I can't find doc for 
SMP/E 3.4.)  Was toleration for long SOURCEIDs introduced by APAR for earlier 
than SMP/E 3.5?  Which APAR?  Or does the above apply only when SMP/E 3.4 
attempts to process a long SOURCEID in a CSI that needs upgrade?

How far back, chronologically and in z/OS release, do support and/or toleration 
for long SOURCEIDs extend?

(BTW, I was told here lately that there's no limit on number of SOURCEIDs for a 
SYSMOD.  But apparently too many can cause operational difficulties:

GIM25903E SMP/E COULD NOT ADD ++ASSIGN SOURCEID sourceid TO SYSMOD ENTRY sysmod 
BECAUSE THE NUMBER OF ELEMENTS IN THE ENTRY EXCEEDED THE CURRENT PEMAX VALUE.
...
Programmer response:

Do the following:
Increase the PEMAX value in the OPTIONS entry being used.
Run UCLIN against the global zone SYSMOD entry to add the SOURCEID value.

I.e. apparently there's a workaround.  Probably not a practical concern.)

Thanks,
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: WER027A control field beyond record

[Longabaugh, Robert E]

>From many years ago I remember using EXEC PGM=SYNCSORT,PARM='VLTEST=0' in the 
>JCL for sorting SMF records.

I think VLTESTI is if you are using INCLUDE or OMIT.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Micheal Butz
Sent: Thursday, February 13, 2014 5:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WER027A control field beyond record

VLTESTI=1.  Cannt figure out were it goes 

Sent from my iPhone

> On Feb 13, 2014, at 8:29 PM, Alan Field  wrote:
> 
> Isn't there a VLSHORT keyword you can specify that will prevent this 
> error?
> 
> Alan Field
> Technical Engineer Principal
> BCBS Minnesota
> 
> Phone: 651.662.3546  Mobile:  651.428.8826
> 
> 
> 
> 
> 
> From:   "Micheal Butz" 
> To: IBM-MAIN@LISTSERV.UA.EDU, 
> Date:   02/13/2014 18:46
> Subject:Re: WER027A control field beyond record
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> SORT FIELDS=(150,4,4,4,A,158,17,A),FORMAT=BI
> MODS.E35=(SORTEX,2,STEPLIB)
> END
> 
> There are a number of records less than 158 Thanks
> 
> Sent from my iPhone
> 
>> On Feb 13, 2014, at 7:30 PM, Ed Gould  wrote:
>> 
>> Michael:
>> 
>> There are several possibilities, but from no real description on what
> you are doing its difficult to suggest anything. ie no display of sort 
> control cards etc...
>> 
>> Ed
>> 
>>> On Feb 13, 2014, at 6:31 PM, Micheal Butz wrote:
>>> 
>>> Seems like one of my sort fields maybe beyond a short record 
>>> Anything I can do about this
>>> 
>>> This
>>> 
>>> Sent from my iPhone
>>> 
>>> 
>>> -- 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

--
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: CA-allocate

[Longabaugh, Robert E]

Hello Hervey,

I work for CA Technologies, and perform QA for CA Allocate.   I also was a 
customer of its predecessors (VAM/VSAM and VAM/DS) in the late 1980s.  As a 
systems programmer I was able get my employer at the time to bring the products 
in and start using them.

CA Allocate basically lets the Storage Administrator override JCL or dynamic 
allocations by the customer.  You write an Allocation Selection Routine and 
test values of certain variables, and then you can make overrides if the 
environment exists.  For example, you can look at a data set name and change 
the SMS storage class.

When I was a customer, we were starting to implement pooling of DASD.  Before 
that, departments owned volumes and programmers had to request allocations on a 
specific volser.  I used it to override the allocation to "the test pool" or 
"the production pool".  

Since that time, we have added support to extend data sets to add space, or to 
reduce allocations to fit on fragmented volumes.  There is also a quota feature 
that allows you to warn or deny allocations to users that have exceeded their 
space allotment.

For most of the time at CA, I have been working on CA Disk and CA Vantage, and 
just started working with CA Allocate again earlier this year.  There are other 
members of this discussion board who have been using it on a more continuous 
basis than I have so you can also pick up a lot of useful information from 
others here, but I will help you with whatever you need, or go to the source to 
find out. 


Regards,
Bob Longabaugh
CA Technologies
Quality Assurance Architect 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Monday, October 07, 2013 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA-allocate

Anybody out there use or have converted to CA-Allocate?  If so, can you share 
your opinion on the product? I've been looking for reviews of the product and 
just don't seem to find anything.




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