Re: IEBUPDTE question

[Edward Gould]

> On Nov 20, 2017, at 10:49 PM, Tony Thigpen  wrote:
> 
> Hundred+ members. As I mentioned (but it got lost in the what is midnight 
> argument), I used a CBT program to perform the adds. I just modified it to 
> pass-though the ./ INCLUDE cards as data cards.
> 
> Tony Thigpen
> 
Tony,

I was going to suggest the CBT tape, but I don’t keep a current copy of the 
contents on my computer, plus I don’t have SPF to manipulate contents. I used 
the same program many a time and came to love it. It is sorely missed and if I 
ever run across it for the MAC I will buy it.

Ed

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

Re: IEBUPDTE question

[Edward Gould]

> On Nov 20, 2017, at 8:11 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 20 Nov 2017 19:05:17 -0600, Edward Gould wrote:
> 
>>> On Nov 20, 2017, at 2:55 PM, Paul Gilmartin wrote:
>>> 
>>> If it were a PDS I'd recommend IEBCOPY and AMATERSE.
>> 
>> It is a psuedo standard [the operant adjective is "pseudo" -- gil] for 
>> *AGES* too use iebupdte (or what ever the VM equivalence is). I have not 
>> been heavily into VM but I believe since day 1 vm source updates have been 
>> iebupdte type format  for OS (PCP-MFT-MVT)
>> 
> An archaic and onerous restriction (I won't deign to call this a "standard") 
> can often
> be relieved by an enhancement.  I have a simple implementation in mind, but 
> IBM
> prefers that RFEs avoid suggesting implementations and mention only 
> requirements.

This is in the realm I believe of a SHARE req (or what ever its called when it 
would crosses product lines such as MVS and VM). I am sure they might listen 
but you would have to get the two products to agree, but good luck I don’t 
think its going to happen any time soon.
> 
>> Its a portable way of doing things IEBCOPY for source is used (I believe) 
>> only for clists and maybe some netview and misc others. JES2 & 3 both use it 
>> for distributed source members. There are other examples.
>> To put it bluntly you are arguing a standard that won’t go away any time 
>> soon, unless a replacement is found.
>> BTW IBM blew it day 1 for lists as clist put sequence numbers in 1-8 rather 
>> than 72. It took a number of share/guides to get IBM to figure out that 
>> iebupdte won’t work with clists. IBM quietly just went to iebcopy for clists 
>> and then on top of that CLISTS are VB in length which is NOT iebupdte 
>> friendly.
>> 
> I suspect 1-8 was an intended accommodation to VB.  And in another apparent
> accommodation, ISPF Edit until recently would not create an 8-character record
> but always padded it with an additional blank.
I don’t think so as SPF wasn’t around when MVS first came out. I “think” it was 
5 or so years afterwards, so that wasn’t the reason.
> 
>> We were probably in the top 100 nationwide to do MVS in production. We saw 
>> the issue day 2. We sat back and watched IBM argue amongst themselves how 
>> they were going to handle CLIST. The first time we fired up SMP we could see 
>> the issue as IBM wrestled with what to use to update. I *think* netview used 
>> 80 for it's “clist”.
>> 
> In days of yore panel definitions for SPF (now known as ISPF) were VB.  
> Abruptly
> they changed to FB.  Disruptively -- it broke all my customized panels.  
> Cognoscenti
> surmised this was an accommodation to SMP(/E) and IEBUPDTE.

I will admit that I am leary of that explanation, but when spf came out we 
laughed at it and called it a resource hog and went in another direction, 
Instead of panels and etc we stuck with edit and a competitor of SPF FSE. I do 
not remember the panels of SPF being VB but I will defer to you and others .
> 
>> Way back then when I was a junior sysprog going to Guide wasn’t possible 
>> until it came to Chicago. The senior sysprog at the time was on one of the 
>> committees (don’t ask its been a LONG time ago) and he would tell us about 
>> the arguments that arose about clists and it got to be fun according to him 
>> seeing IBM trying to argue the point. I know our IBM SE was almost swept up 
>> in it (IBM internals). He politely refused to get involved. If people don’t 
>> remember at one time the CDS was in PDS format (IBM sort of broke the rules 
>> on that one) when SMPE came out and converted the pds to a Vsam dataset all 
>> was good again. Firing up SMP was a big resource hog as it read (IIRC) the 
>> CDS directory into memory. The SMP zone was a PDS as well but it was 
>> manageable, Its been years so my memory might be faulty here, the CDS (at 
>> least at our installation was created with 20,000 members (or more). 
>> 
> I thought that nowadays SMP/E keeps everything in VSAM except its libraries.
> At least I've never coded DDDEFs (that's what I use instead of JCL DD) for any
> nonVSAM zone files.
It does. I was talking about pre SMPE. 
> 
>> The first indications that IBM needed to “fix” pds’s was because of SMP and 
>> somewhere along the line IBM decided to replace PDS’s with PDSe’s, I don’t 
>> remember what caused the decision, but (again here my memory is iffy) is 
>> that SMP CDS’s were bumping the limits of PO type datasets.
>> 
> PDSEs have DSORG=PO.  (But I believe that's a benign fiction with the goal of 
> compatibility)
I was clearly talking about CDS’s being a huge animal (Pre VSAM and pre PDSE) 
and like I said (I don’t clearly remember) what caused IBM to redo the thought 
process of changing to VSAM, other than possible limits on the number of 
directory blocks. My memory is cloudy here but the actual content of each 
member was small 1 record (But I could be wrong). The trick IBM used was to use 
upper/lower case 

Re: IEBUPDTE question

[Tony Thigpen]

Hundred+ members. As I mentioned (but it got lost in the what is 
midnight argument), I used a CBT program to perform the adds. I just 
modified it to pass-though the ./ INCLUDE cards as data cards.


Tony Thigpen

Wayne Bickerdike wrote on 11/20/2017 11:39 PM:

oops,

Change all the unwanted ./ cards to ## or similar. After the IEBUPDTE,
change them back to ./

On Tue, Nov 21, 2017 at 3:32 PM, Wayne Bickerdike  wrote:


Assuming the cards with a ./ don't have the correct syntax, why not do an
EXCLUDE ALL, FIND ALL ./.

EXCLUDE all the correct ./ cards and then do a DEL ALL NX



On Mon, Nov 20, 2017 at 2:45 PM, Tony Thigpen  wrote:


I need to catalog a bunch of jobs into a PDS during a conversion. The
source system utility creates an IEBUPDTE job for this purpose.

Unfortunately, some of the data within these jobs steams contain a './'
at the start of the card record. IEBUPDTE thinks they are control cards and
cancels the catalog of the new member.

At this point, the only thing I think should work is to individually FTP
these members and bypass IEBUPDTE, but that will be a real hassle.

I am looking for suggestions on how to get these members cataloged.

--
Tony Thigpen

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





--
Wayne V. Bickerdike







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

Re: IEBUPDTE question

[Wayne Bickerdike]

oops,

Change all the unwanted ./ cards to ## or similar. After the IEBUPDTE,
change them back to ./

On Tue, Nov 21, 2017 at 3:32 PM, Wayne Bickerdike  wrote:

> Assuming the cards with a ./ don't have the correct syntax, why not do an
> EXCLUDE ALL, FIND ALL ./.
>
> EXCLUDE all the correct ./ cards and then do a DEL ALL NX
>
>
>
> On Mon, Nov 20, 2017 at 2:45 PM, Tony Thigpen  wrote:
>
>> I need to catalog a bunch of jobs into a PDS during a conversion. The
>> source system utility creates an IEBUPDTE job for this purpose.
>>
>> Unfortunately, some of the data within these jobs steams contain a './'
>> at the start of the card record. IEBUPDTE thinks they are control cards and
>> cancels the catalog of the new member.
>>
>> At this point, the only thing I think should work is to individually FTP
>> these members and bypass IEBUPDTE, but that will be a real hassle.
>>
>> I am looking for suggestions on how to get these members cataloged.
>>
>> --
>> Tony Thigpen
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> Wayne V. Bickerdike
>
>


-- 
Wayne V. Bickerdike

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

Re: IEBUPDTE question

[Wayne Bickerdike]

Assuming the cards with a ./ don't have the correct syntax, why not do an
EXCLUDE ALL, FIND ALL ./.

EXCLUDE all the correct ./ cards and then do a DEL ALL NX



On Mon, Nov 20, 2017 at 2:45 PM, Tony Thigpen  wrote:

> I need to catalog a bunch of jobs into a PDS during a conversion. The
> source system utility creates an IEBUPDTE job for this purpose.
>
> Unfortunately, some of the data within these jobs steams contain a './' at
> the start of the card record. IEBUPDTE thinks they are control cards and
> cancels the catalog of the new member.
>
> At this point, the only thing I think should work is to individually FTP
> these members and bypass IEBUPDTE, but that will be a real hassle.
>
> I am looking for suggestions on how to get these members cataloged.
>
> --
> Tony Thigpen
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: ARC0734i rc=20 reason=98

[Anthony Thompson]

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

Ant.

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

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


Hervey



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

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

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

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


Hervey



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

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

See message arc1220I RC=98 for explanation.

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

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

HTH,

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

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

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

Any ideas?

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


::DISCLAIMER::


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




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

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

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

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

Re: IEBUPDTE question

[Paul Gilmartin]

On Mon, 20 Nov 2017 19:05:17 -0600, Edward Gould wrote:

>> On Nov 20, 2017, at 2:55 PM, Paul Gilmartin wrote:
>> 
>> If it were a PDS I'd recommend IEBCOPY and AMATERSE.
>
>It is a psuedo standard [the operant adjective is "pseudo" -- gil] for *AGES* 
>too use iebupdte (or what ever the VM equivalence is). I have not been heavily 
>into VM but I believe since day 1 vm source updates have been iebupdte type 
>format  for OS (PCP-MFT-MVT)
>
An archaic and onerous restriction (I won't deign to call this a "standard") 
can often
be relieved by an enhancement.  I have a simple implementation in mind, but IBM
prefers that RFEs avoid suggesting implementations and mention only 
requirements.

>Its a portable way of doing things IEBCOPY for source is used (I believe) only 
>for clists and maybe some netview and misc others. JES2 & 3 both use it for 
>distributed source members. There are other examples.
>To put it bluntly you are arguing a standard that won’t go away any time soon, 
>unless a replacement is found.
>BTW IBM blew it day 1 for lists as clist put sequence numbers in 1-8 rather 
>than 72. It took a number of share/guides to get IBM to figure out that 
>iebupdte won’t work with clists. IBM quietly just went to iebcopy for clists 
>and then on top of that CLISTS are VB in length which is NOT iebupdte friendly.
>
I suspect 1-8 was an intended accommodation to VB.  And in another apparent
accommodation, ISPF Edit until recently would not create an 8-character record
but always padded it with an additional blank.

>We were probably in the top 100 nationwide to do MVS in production. We saw the 
>issue day 2. We sat back and watched IBM argue amongst themselves how they 
>were going to handle CLIST. The first time we fired up SMP we could see the 
>issue as IBM wrestled with what to use to update. I *think* netview used 80 
>for it's “clist”.
>
In days of yore panel definitions for SPF (now known as ISPF) were VB.  Abruptly
they changed to FB.  Disruptively -- it broke all my customized panels.  
Cognoscenti
surmised this was an accommodation to SMP(/E) and IEBUPDTE.

>Way back then when I was a junior sysprog going to Guide wasn’t possible until 
>it came to Chicago. The senior sysprog at the time was on one of the 
>committees (don’t ask its been a LONG time ago) and he would tell us about the 
>arguments that arose about clists and it got to be fun according to him seeing 
>IBM trying to argue the point. I know our IBM SE was almost swept up in it 
>(IBM internals). He politely refused to get involved. If people don’t remember 
>at one time the CDS was in PDS format (IBM sort of broke the rules on that 
>one) when SMPE came out and converted the pds to a Vsam dataset all was good 
>again. Firing up SMP was a big resource hog as it read (IIRC) the CDS 
>directory into memory. The SMP zone was a PDS as well but it was manageable, 
>Its been years so my memory might be faulty here, the CDS (at least at our 
>installation was created with 20,000 members (or more). 
>
I thought that nowadays SMP/E keeps everything in VSAM except its libraries.
At least I've never coded DDDEFs (that's what I use instead of JCL DD) for any
nonVSAM zone files.

>The first indications that IBM needed to “fix” pds’s was because of SMP and 
>somewhere along the line IBM decided to replace PDS’s with PDSe’s, I don’t 
>remember what caused the decision, but (again here my memory is iffy) is that 
>SMP CDS’s were bumping the limits of PO type datasets.
>
PDSEs have DSORG=PO.  (But I believe that's a benign fiction with the goal of 
compatibility)

-- gil

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

Re: IEBUPDTE question

[Edward Gould]

> On Nov 20, 2017, at 2:55 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> But it's not a PDS, but Condor will export it in a useless format resembling
> IEBUPDTE?
> 
> If it were a PDS I'd recommend IEBCOPY and AMATERSE.
> 
> It appears that the Condor has its talons in the CamLib and doesn't
> want to let it go.  Have you asked Phoenix?  Their representatives on
> this list have been helpful.
> 
> — gil

Gil,
It is a psuedo standard for *AGES* too use iebupdte (or what ever the VM 
equivalence is). I have not been heavily into VM but I believe since day 1 vm 
source updates have been iebupdte type format  for OS (PCP-MFT-MVT)
Its a portable way of doing things IEBCOPY for source is used (I believe) only 
for clists and maybe some netview and misc others. JES2 & 3 both use it for 
distributed source members. There are other examples.
To put it bluntly you are arguing a standard that won’t go away any time soon, 
unless a replacement is found.
BTW IBM blew it day 1 for lists as clist put sequence numbers in 1-8 rather 
than 72. It took a number of share/guides to get IBM to figure out that 
iebupdte won’t work with clists. IBM quietly just went to iebcopy for clists 
and then on top of that CLISTS are VB in length which is NOT iebupdte friendly.
We were probably in the top 100 nationwide to do MVS in production. We saw the 
issue day 2. We sat back and watched IBM argue amongst themselves how they were 
going to handle CLIST. The first time we fired up SMP we could see the issue as 
IBM wrestled with what to use to update. I *think* netview used 80 for it's 
“clist”.
Way back then when I was a junior sysprog going to Guide wasn’t possible until 
it came to Chicago. The senior sysprog at the time was on one of the committees 
(don’t ask its been a LONG time ago) and he would tell us about the arguments 
that arose about clists and it got to be fun according to him seeing IBM trying 
to argue the point. I know our IBM SE was almost swept up in it (IBM 
internals). He politely refused to get involved. If people don’t remember at 
one time the CDS was in PDS format (IBM sort of broke the rules on that one) 
when SMPE came out and converted the pds to a Vsam dataset all was good again. 
Firing up SMP was a big resource hog as it read (IIRC) the CDS directory into 
memory. The SMP zone was a PDS as well but it was manageable, Its been years so 
my memory might be faulty here, the CDS (at least at our installation was 
created with 20,000 members (or more). 
The first indications that IBM needed to “fix” pds’s was because of SMP and 
somewhere along the line IBM decided to replace PDS’s with PDSe’s, I don’t 
remember what caused the decision, but (again here my memory is iffy) is that 
SMP CDS’s were bumping the limits of PO type datasets.

Ed




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

Re: ARC0734i rc=20 reason=98

[Jesse 1 Robinson]

There has always been a general restriction that SMS managed data sets must be 
cataloged. If you try to uncatalog an SMS data set, it will (should?) fail. 

In our shop, tape data sets are not SMS managed, so we can (and do) keep some 
uncataloged data sets indefinitely. CA-1 made that fairly easy. RMM was 
initially quite unhappy with uncataloged data sets but has since negotiated an 
uneasy peace. 

.
.
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 Paul Gilmartin
Sent: Monday, November 20, 2017 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ARC0734i rc=20 reason=98

On Mon, 20 Nov 2017 14:03:15 -0600, John McKown wrote:
>
>​Oh, I've had that problem. Look at the GDG base in the catalog. Make 
>sure that it says "SCRATCH". Otherwise the GDG data set entry will "roll off"
>the GDG, but the data set will not be scratched from the volume. I had 
>a big problem with this when programmers were allowed to create their 
>own GDGs and they _never_ put the SCRATCH parameter on the DEFINE GDG. 
>Why the bleeding  IBM made the default NOSCRATCH is a mystery 
>know to none at this point.​
> 
It appears that the GDG designers, the SMS designers, and the catalog designers 
don't coordinate very well with each other.  Otherwise, SMS strives mightily to 
avoid orphaned data sets.

-- gil


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

Re: ARC0734i rc=20 reason=98

[Paul Gilmartin]

On Mon, 20 Nov 2017 14:03:15 -0600, John McKown wrote:
>
>​Oh, I've had that problem. Look at the GDG base in the catalog. Make sure
>that it says "SCRATCH". Otherwise the GDG data set entry will "roll off"
>the GDG, but the data set will not be scratched from the volume. I had a
>big problem with this when programmers were allowed to create their own
>GDGs and they _never_ put the SCRATCH parameter on the DEFINE GDG. Why the
>bleeding  IBM made the default NOSCRATCH is a mystery know to none
>at this point.​
> 
It appears that the GDG designers, the SMS designers, and the catalog designers
don't coordinate very well with each other.  Otherwise, SMS strives mightily
to avoid orphaned data sets.

-- gil

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

Re: ARC0734i rc=20 reason=98

[Hervey Martinez]

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


Hervey



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

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

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

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


Hervey



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

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

See message arc1220I RC=98 for explanation.

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

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

HTH,

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

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

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

Any ideas?

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


::DISCLAIMER::


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




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

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

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

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

Re: ARC0734i rc=20 reason=98

[Hervey Martinez]

Yes, that was my initial thought but all GDGs that I've seen have the SCRATCH 
parm.



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

On Mon, Nov 20, 2017 at 1:59 PM, Hervey Martinez 
wrote:

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

Oh, I've had that problem. Look at the GDG base in the catalog. Make sure
that it says "SCRATCH". Otherwise the GDG data set entry will "roll off"
the GDG, but the data set will not be scratched from the volume. I had a
big problem with this when programmers were allowed to create their own
GDGs and they _never_ put the SCRATCH parameter on the DEFINE GDG. Why the
bleeding  IBM made the default NOSCRATCH is a mystery know to none
at this point.



>
>
> Hervey
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Allan Staller 
> Sent: Monday, November 20, 2017 2:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0734i rc=20 reason=98
>
> Non-symetric aliases? i.e. alias A in MCATA, but not in MCATB
>
> See message arc1220I RC=98 for explanation.
>
> Basically get down to one copy of the dataset (whether it is the migrated
> copy or the "real" dataset).
> This will resolve the issue.
>
> As to why, there are too many variables to spend a great deal of time
> speculating.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hervey Martinez
> Sent: Monday, November 20, 2017 1:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ARC0734i rc=20 reason=98
>
> We have several datasets that show up in HSM's miglog file. I know the
> problem is that the file is not cataloged and is the reason for the error.
> My question is: What causes these files to become uncataloged?
>
> I've read a few other posts about the HSM address space being cancelled
> due to errors and causing this sort of error. We only recycle HSM during
> maintenance on the weekends and many of these errors happen during the week
> which does not coincide with the recycling of the HSM task.
>
> Any ideas?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> ::DISCLAIMER::
> 
> 
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> 
> 
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
I have a theory that it's impossible to prove anything, but I can't prove
it.

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 

Re: IEBUPDTE question

[Paul Gilmartin]

On Mon, 20 Nov 2017 12:03:19 -0500, Tony Thigpen wrote:

>Condor from Phoenix Systems. Condor uses the ./ INCLUDE card during job
>submission.
>
>We are not getting away from Condor, but I need to move a couple of
>CamLibs to MVS PDS libs until I can update to a newer release of Condor
>that supports FTP access. (Condor can pretend that a PDS lib is a CamLib
>during this temporary phase so the users don't know the library has been
>relocated.)
> 
But it's not a PDS, but Condor will export it in a useless format resembling
IEBUPDTE?

If it were a PDS I'd recommend IEBCOPY and AMATERSE.

It appears that the Condor has its talons in the CamLib and doesn't
want to let it go.  Have you asked Phoenix?  Their representatives on
this list have been helpful.

-- gil

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

Re: ARC0734i rc=20 reason=98

[Allan Staller]

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

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

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


Hervey



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

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

See message arc1220I RC=98 for explanation.

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

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

HTH,

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

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

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

Any ideas?

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


::DISCLAIMER::


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




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

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

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

Re: ARC0734i rc=20 reason=98

[John McKown]

On Mon, Nov 20, 2017 at 1:59 PM, Hervey Martinez 
wrote:

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

​Oh, I've had that problem. Look at the GDG base in the catalog. Make sure
that it says "SCRATCH". Otherwise the GDG data set entry will "roll off"
the GDG, but the data set will not be scratched from the volume. I had a
big problem with this when programmers were allowed to create their own
GDGs and they _never_ put the SCRATCH parameter on the DEFINE GDG. Why the
bleeding  IBM made the default NOSCRATCH is a mystery know to none
at this point.​



>
>
> Hervey
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Allan Staller 
> Sent: Monday, November 20, 2017 2:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0734i rc=20 reason=98
>
> Non-symetric aliases? i.e. alias A in MCATA, but not in MCATB
>
> See message arc1220I RC=98 for explanation.
>
> Basically get down to one copy of the dataset (whether it is the migrated
> copy or the "real" dataset).
> This will resolve the issue.
>
> As to why, there are too many variables to spend a great deal of time
> speculating.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hervey Martinez
> Sent: Monday, November 20, 2017 1:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ARC0734i rc=20 reason=98
>
> We have several datasets that show up in HSM's miglog file. I know the
> problem is that the file is not cataloged and is the reason for the error.
> My question is: What causes these files to become uncataloged?
>
> I've read a few other posts about the HSM address space being cancelled
> due to errors and causing this sort of error. We only recycle HSM during
> maintenance on the weekends and many of these errors happen during the week
> which does not coincide with the recycling of the HSM task.
>
> Any ideas?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> ::DISCLAIMER::
> 
> 
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> 
> 
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: ARC0734i rc=20 reason=98

[Hervey Martinez]

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


Hervey



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

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

See message arc1220I RC=98 for explanation.

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

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

HTH,

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

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

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

Any ideas?

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


::DISCLAIMER::


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




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

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

Re: ARC0734i rc=20 reason=98

[Allan Staller]

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

See message arc1220I RC=98 for explanation.

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

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

HTH,

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

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

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

Any ideas?

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


::DISCLAIMER::


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




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

ARC0734i rc=20 reason=98

[Hervey Martinez]

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

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

Any ideas?

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

Useful little utility?

[John McKown]

This is a small ISPF based utility. I call it SYSPARM because it brings up
a ISPF option 3.4 like DSN list which contains the system PARMLIB
concatenation. It might be a nice way to find out where a specific PARMLIB
member is: e.g. Where is TSOKEY27??

It is 140 lines of HLASM code. I wrote in on z/OS 1.12 and tested it on a
2.3 system as well. Basically it uses IEFPRMLB REQUEST=ALLOCATE to allocate
the system PARMLIB and then does an ISRDDN ONLY to display that allocation.

ref: https://github.com/JohnArchieMckown/miscutil/blob/master/SYSPARM

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IEBUPDTE question

[Tony Thigpen]

Condor from Phoenix Systems. Condor uses the ./ INCLUDE card during job 
submission.


We are not getting away from Condor, but I need to move a couple of 
CamLibs to MVS PDS libs until I can update to a newer release of Condor 
that supports FTP access. (Condor can pretend that a PDS lib is a CamLib 
during this temporary phase so the users don't know the library has been 
relocated.)


Tony Thigpen

Paul Gilmartin wrote on 11/20/2017 11:57 AM:

On Sun, 19 Nov 2017 22:45:10 -0500, Tony Thigpen wrote:


I need to catalog a bunch of jobs into a PDS during a conversion. The
source system utility creates an IEBUPDTE job for this purpose.


Just curious: what are the "source system" and its "utility"?

The "shar" (shell archive) utility, not POSIX but widely available, does
this sort of thing nicely.


Unfortunately, some of the data within these jobs steams contain a './'
at the start of the card record. IEBUPDTE thinks they are control cards
and cancels the catalog of the new member.


The designers of IEBUPDTE had dreadful tunnel vision in failing
to anticipate that your problem would never occur.  Job streams
containing IEBUPDTE steps are commonplace.

-- 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: ECVTDUCU & "trap" condition in z/OS

[Farley, Peter x23353]

Sounds good to me EXCEPT for the "key 0, supervisor state" requirement.

Sounds like we also need a system-supplied PC service that can be invoked from 
normal non-supervisor-state, non-zero-key application code to utilize the TRAP 
facilities (both enabling and disabling).

Peter R. or John E., would you care to comment on this?  Is there any chance 
that normal application-level code will be able use this facility any time soon?

And yes, I understand that you cannot comment on future directions, but any 
clue would be helpful.  At least we would have a some idea how long we have to 
wait for it.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, November 20, 2017 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ECVTDUCU & "trap" condition in z/OS

EXTERNAL: This email originated from outside of Broadridge. Do not click any 
links or open any attachments unless you trust the sender and know the content 
is safe.

On Mon, Nov 20, 2017 at 10:36 AM, Farley, Peter x23353 < 
peter.far...@broadridge.com> wrote:

> That is interesting John.  No such field in my V2.1 MODGEN library 
> member IHAECVT.  What offset it that at in your copy?
>

​Apparently came in with 2.2

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100662.htm

268 (10C) ADDRESS 4  ECVTDUCU "V(IEAVDUCU)" - DUCT update - A value of 0 in 
ECVTDUCU means that the function is not available - Caller must be AMODE 31 or 
64, key 0, supervisor state - Task mode - Primary ASC mode - Any P, Any S, Any 
H - To invoke the service: - Set GR 1 to 1 to indicate to update the TRAP 
Control Block Address - Set GR 0 to the address of the doubleword aligned TRAP 
Control Block Address (below 2G). Bits 0-31 of 64-bit GR0 are ignored. A 
non-zero value in bits 32-63 will enable the TRAP function. When enabling, bit 
63 is ignored. Bits 61-62 must be 0. Use a value of 0 in bits
32-63 to disable the TRAP function. - Load ECVTDUCU into GR 15. Do not use the 
LLGT instruction. You do not need to set bits 0-31 of 64-bit GR 15. - If AMODE 
64, issue BASSM 14,15 If AMODE 31, issue BASR 14,15 or BASSM 14,15
- Upon return from the service - 31-bit GRs 2-13, high halves 2-14, and ARs
2-14 will be preserved. Other GRs, high halves, and ARs may be used as work 
registers by the system. - On return R15 contains a return code 0 - success
8 - bad value in register 1 12 - TRAP update request in SRB mode ​

>
> One would HOPE such a field would be used by full z/OS support for 
> actually USING the TRAPx functionality (along with the several 
> compare-and-trap instructions too).
>
> Perhaps a "future use" field?
>
> Peter
>
>

--


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


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

Re: IEBUPDTE question

[Paul Gilmartin]

On Sun, 19 Nov 2017 22:45:10 -0500, Tony Thigpen wrote:

>I need to catalog a bunch of jobs into a PDS during a conversion. The
>source system utility creates an IEBUPDTE job for this purpose.
> 
Just curious: what are the "source system" and its "utility"?

The "shar" (shell archive) utility, not POSIX but widely available, does
this sort of thing nicely.

>Unfortunately, some of the data within these jobs steams contain a './'
>at the start of the card record. IEBUPDTE thinks they are control cards
>and cancels the catalog of the new member.
> 
The designers of IEBUPDTE had dreadful tunnel vision in failing
to anticipate that your problem would never occur.  Job streams
containing IEBUPDTE steps are commonplace.

-- gil

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

Re: ECVTDUCU & "trap" condition in z/OS

[John McKown]

On Mon, Nov 20, 2017 at 10:36 AM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> That is interesting John.  No such field in my V2.1 MODGEN library member
> IHAECVT.  What offset it that at in your copy?
>

​Apparently came in with 2.2

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100662.htm

268 (10C) ADDRESS 4  ECVTDUCU "V(IEAVDUCU)" - DUCT update - A value of 0 in
ECVTDUCU means that the function is not available - Caller must be AMODE 31
or 64, key 0, supervisor state - Task mode - Primary ASC mode - Any P, Any
S, Any H - To invoke the service: - Set GR 1 to 1 to indicate to update the
TRAP Control Block Address - Set GR 0 to the address of the doubleword
aligned TRAP Control Block Address (below 2G). Bits 0-31 of 64-bit GR0 are
ignored. A non-zero value in bits 32-63 will enable the TRAP function. When
enabling, bit 63 is ignored. Bits 61-62 must be 0. Use a value of 0 in bits
32-63 to disable the TRAP function. - Load ECVTDUCU into GR 15. Do not use
the LLGT instruction. You do not need to set bits 0-31 of 64-bit GR 15. -
If AMODE 64, issue BASSM 14,15 If AMODE 31, issue BASR 14,15 or BASSM 14,15
- Upon return from the service - 31-bit GRs 2-13, high halves 2-14, and ARs
2-14 will be preserved. Other GRs, high halves, and ARs may be used as work
registers by the system. - On return R15 contains a return code 0 - success
8 - bad value in register 1 12 - TRAP update request in SRB mode
​



>
> One would HOPE such a field would be used by full z/OS support for
> actually USING the TRAPx functionality (along with the several
> compare-and-trap instructions too).
>
> Perhaps a "future use" field?
>
> Peter
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: ECVTDUCU & "trap" condition in z/OS

[Farley, Peter x23353]

That is interesting John.  No such field in my V2.1 MODGEN library member 
IHAECVT.  What offset it that at in your copy?

One would HOPE such a field would be used by full z/OS support for actually 
USING the TRAPx functionality (along with the several compare-and-trap 
instructions too).

Perhaps a "future use" field?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, November 20, 2017 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ECVTDUCU & "trap" condition in z/OS

EXTERNAL: This email originated from outside of Broadridge. Do not click any 
links or open any attachments unless you trust the sender and know the content 
is safe.

I just stumbled upon this field in SYS1.MODGEN, member IHAECVT. This appears at 
first glance to be for the TRAP, TRAP4, and perhaps the  AND TRAP instructions. But I don't really see _anything_ else 
something> in
SYS1.MACLIB or SYS1.MODGEN that references this field.

Anybody got a link to the secret documentation? Or is it one of those "
but then I'd be forced to kill you" type situations.

--


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


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

Re: IEBUPDTE question

[Tony Thigpen]

Thanks all.

I have resolved the issue. I extracted PDSLOAD from CBT 316, then 
modified it to retain the ./ INCLUDE as data cards. (Yes, I need to keep 
them in the members as such.)


Tony Thigpen

Wendell Lovewell wrote on 11/20/2017 09:40 AM:

Hey Tony,

For $1000 a year our Global Search and Replace can unload and load a whole PDS, 
optionally making changes to the members.  Maybe not a great one-time solution 
but a handy tool to have around.

You could write a REXX program to read the file and call IEBUPDTE for each 
member, ignoring the ./ records.

Myself, if I was starting with a PC file, I'd write a KEDIT macro to split them 
up and use FTP with MPUT.

Wendell Lovewell
MacKinney Systems

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

ECVTDUCU & "trap" condition in z/OS

[John McKown]

I just stumbled upon this field in SYS1.MODGEN, member IHAECVT. This
appears at first glance to be for the TRAP, TRAP4, and perhaps the  AND TRAP instructions. But I don't really see _anything_ else in
SYS1.MACLIB or SYS1.MODGEN that references this field.

Anybody got a link to the secret documentation? Or is it one of those "
but then I'd be forced to kill you" type situations.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: IEBUPDTE question

[Wendell Lovewell]

Hey Tony, 

For $1000 a year our Global Search and Replace can unload and load a whole PDS, 
optionally making changes to the members.  Maybe not a great one-time solution 
but a handy tool to have around.

You could write a REXX program to read the file and call IEBUPDTE for each 
member, ignoring the ./ records. 

Myself, if I was starting with a PC file, I'd write a KEDIT macro to split them 
up and use FTP with MPUT. 

Wendell Lovewell
MacKinney Systems

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

Re: TSSO vs. System REXX for a "new user who is poor".

[John McKown]

Given the small number of responses, I doubt that spending much time
"cleaning up" TSSO would be "cost effective". So I'm just going to put in
the IEFPRMLB processing to enhance the finding of TSSO's configuration
member and let it go at that.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: doubt on catalog

[johnnydeep san]

on RDZ ,SYSA lpar we mentioned script like this" 0A91  3390
C:\**\***\  "   ,  is non-sms volume i installed  product
using smpe  and place the all required data-set on
  .  Now we planned to use the same product  on SYST , instead of
installing the product from scratch , we planed to go with volume transfer
. so we include the below
 " 0A91  3390  C:\**\***\  "  on  SYST devmap.

On Mon, Nov 20, 2017 at 5:36 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> johnnydeep san wrote:
>
> >>Is the dasd shared?  Or did you transfer to new system?
> >DASD is not shared , i transferred to new system
>
> How did you transferred them to the new system? Perhaps you used incorrect
> settings or cataloging process.
>
> Please post the job and results of your transfer attempt.
>
> 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: doubt on catalog

[Elardus Engelbrecht]

johnnydeep san wrote:

>>Is the dasd shared?  Or did you transfer to new system?
>DASD is not shared , i transferred to new system

How did you transferred them to the new system? Perhaps you used incorrect 
settings or cataloging process.

Please post the job and results of your transfer attempt.

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

Re: doubt on catalog

[johnnydeep san]

Lizette,

Thanks for your response !! . ,please find my answer below

How did you get the datasets to the new system?

I'm using volume () which has all required dataset for bring up the
software . .   FYI - i'm using RDZ  , there is no sysplex , i have sysa and
syst both are separated  lpar using separate volumes.( all i want to use
the software in syst which  i was used in sysa. Instead of installing a
software again  on syst, i planed to use it by transferring   volume
alone ).

What HLQ are you using ?

I used HLq called  VIM.*  in  sysa.

Do you have separate master catalogs?  One on system A and one on system T ?

we dint create any usercatlog on both system system. Yes, we have separate
master catalog for both system.


Is the dasd shared?  Or did you transfer to new system?
DASD is not shared , i transferred to new system

+JD+


On Sun, Nov 19, 2017 at 8:10 PM, Lizette Koehler 
wrote:

> How did you get the datasets to the new system?
>
> What HLQ are you using
>
> Do you have separate master catalogs?  One on system A and one on system T
>
> Is the dasd shared?  Or did you transfer to new system?
>
>
> The only way the new system can see the datasets will depend on how your
> shop deploys z/OS to new hosts.
>
> Some rules
>
>1)  Do not share DASD between plexes.  This can damage the datasets
>2)  Best practice is to have a standardized process to move SMPE
> libraries to new hosts
>a) Typically you will have TLIBs and DLIBs.  You only need (in most
> cases) the TLIB datasets
>b) PDS/E can be damaged if you share them between plexes (even
> Monoplex)
>c) DFDSS Dump restore can be a friend
>3)  Most SYS1 type datasets are cataloged in a master catalog.
>a) It is preferred to not share master catalogs between monoplexes
>
>
> Please provide more details on how you transferred the datasets to system
> T.  How you cataloged them on System T.  What the HLQ is for the datasets
> being transferred to system T
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of johnnydeep san
> > Sent: Sunday, November 19, 2017 5:51 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: doubt on catalog
> >
> > Hello  all,
> >
> > I have software(smpe and prodcut based dataset both vsam and non-vsam)
> > resides in volume   on system A, i would like to use the same
> software
> > resides in  on another monoplex system (system t) for testing.
> >
> > while bring up the  software , i faced 'dataset not found '  even though
> it
> > resides in volume. later came to know  issues is  with catalog,since this
> > hlq's are not identified by syst.
> >
> > How can i make all these data-sets  to be understandable to the system
> system
> > t.I'm linux folk learning mainframe,please guide me .
> >
> >
> > +JD+
> >
>
> --
> 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