Re: IEBUPDTE question

[Edward Gould]

> On Nov 21, 2017, at 10:24 AM, Jesse 1 Robinson  
> wrote:
> 
> In addition to IEBUPDTE-like utilities, StarTool (and I would hope its CBT 
> predecessor) has a REPLACE function that can scan an entire PDS(E) and 
> replace one string with another as long the result does not exceed line 
> length. It allows such filters as WORD, PREFIX, and SUFFIX. You can make a 
> trial run to examine the results without actually updating anything before 
> doing it for real. Several other options are included as well. Something to 
> keep in mind. 
> 
> .
> .

Skip:

I never had the free tool, I always used the $$ version. I also will freely 
admit it has saved my ass many a time. Little story: Way back in the XA days, 
we had just put an enormous number of JES2 fixes on and I *DID* look at each 
hold on the 30-40 fixes. None of them mentioned the fact that JES2 would no 
longer accept a specific JECL parameter. About 0500 I had just let the 
production system go, so they started to run jobs. About 5 minutes later I get 
a call saying something is wrong and the JECL parameter is flagged as an error. 
I started to look at it and to me it seemed valid, so I headed for the manual 
and it agreed with what I was saying it was valid. I was sweating as I didn’t 
want to back out all the maintenance. I looked at other option and found one. I 
had no idea how many of these were in production. I did a quick scan of the 
library where production came out of and found 10 jobs. I said to myself go for 
it, so I did a scan/replace and it found the 10 jobs. I called back to 
production control and asked them too resubmit. Just about the time he 
submitted it, The VP walked into the office of the supervisor where I was at 
and asked if we should back out as we had until 6 AM of the stock markets would 
not open. I said wait one minute and I called back to production control and 
the job ran successfully. I turned around to the VP and said, no everything is 
fine. He looked at me and said he had been told there was a major issue and I 
said no sir, it was a minor issue which has been fixed. After that morning I 
went back through every JES2 fix that went on and there was NOT a single hold. 
I then went back and read the cover letters and found the blasted fix. I called 
in to the support center and bitched at the level 1 people and asked to be 
connected to level 2. I let level 2 know in no uncertain terms that a HOLD was 
mandatory for something like this. I didn’t get a lot of oops we are sorry, so 
at the next SHARE, I buttonholed one of the JES2 IBMers and raged on him. From 
then on JES2 was good at putting out holds on PTFS.
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

[Paul Gilmartin]

On Tue, 21 Nov 2017 19:14:30 -0600, Edward Gould wrote:
>> 
 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, ...
 
>> Why?
>
>Way back then concatenation of VB and FB wasn’t available.
>
But that's exactly what broke my customized panels when IBM changed
their panels from VB to FB.  Concatenating mine with theirs suddenly
failed where it had worked as long as IBM's panels were VB.

-- 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 21, 2017, at 12:27 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Have  you a more plausible conjecture?  If not, I'm sticking with mine.  And
> the chronology you assume fits with my explanation.
> 
>>> 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, ...
>>> 
> Why?

Way back then concatenation of VB and FB wasn’t available.
Ed
> 
> -- 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

[Paul Gilmartin]

On Mon, 20 Nov 2017 23:15:14 -0600, Edward Gould wrote:
>
>> 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.
>
Have  you a more plausible conjecture?  If not, I'm sticking with mine.  And
the chronology you assume fits with my explanation.

>> 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, ...
>> 
Why?

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

[Paul Gilmartin]

On Tue, 21 Nov 2017 15:32:37 +1100, 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
> 
I asumed he wanted them preserved as data records, not deleted.

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

[Jesse 1 Robinson]

In addition to IEBUPDTE-like utilities, StarTool (and I would hope its CBT 
predecessor) has a REPLACE function that can scan an entire PDS(E) and replace 
one string with another as long the result does not exceed line length. It 
allows such filters as WORD, PREFIX, and SUFFIX. You can make a trial run to 
examine the results without actually updating anything before doing it for 
real. Several other options are included as well. Something to keep in mind. 

.
.
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 Tony Thigpen
Sent: Monday, November 20, 2017 8:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEBUPDTE question

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 <wayn...@gmail.com> 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 <t...@vse2pdf.com> 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
>> --
>> 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

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

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: IEBUPDTE question

[Arthur]

On 19 Nov 2017 19:43:57 -0800, in bit.listserv.ibm-main 
(Message-ID:<5a124fc6.3070...@vse2pdf.com>) 
t...@vse2pdf.com (Tony Thigpen) wrote:


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 CBT tape has a utility that will work like IEBUPDTE, 
but you to specify a different two characters for "real" 
control statements.  You can either rerun the offload with 
the new program, or hand-edit the input.  The former is 
probably easier.


I forget which one I used.  It's probably file 93, but I 
see another at file 684.


Search for UPDTE on page 
http://www.cbttape.org/cbtdowns.htm 


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

IEBUPDTE question

[Tony Thigpen]

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