Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Issue with copying PDS members to another PDS

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CLIST & REXX
View previous topic :: :: View next topic  
Author Message
Senthilkumar k
Warnings : 1

New User


Joined: 07 May 2009
Posts: 51
Location: Chennai

PostPosted: Mon Apr 20, 2015 1:28 pm    Post subject: Issue with copying PDS members to another PDS
Reply with quote

Hi All,
I have used below command to copy PDS members from one pds to another.

Code:
ADDRESS TSO 'COPY from pds(member) topds(mem)'



All the members were copied successfully but i am getting the output by setting the SPACES as ZEROS.

for example, from member is a COBOl program like below,
Code:

000026        ENVIRONMENT DIVISION.   
000027        CONFIGURATION SECTION. 
000028        INPUT-OUTPUT SECTION.   
000029        FILE-CONTROL.           


i am getting to pds member like below,

Code:

000026 00000  ENVIRONMENT DIVISION.   
000027 00000  CONFIGURATION SECTION.   
000028 00000  INPUT-OUTPUT SECTION.   
000029 00000  FILE-CONTROL.           


those extra ZEROS were coming in my to PDS member wherever the SPACES are available.
Back to top
View user's profile Send private message

enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10203
Location: italy

PostPosted: Mon Apr 20, 2015 1:55 pm    Post subject: Reply to: Issue with copying PDS members to another PDS
Reply with quote

COPY is NOT a command provided by vanilla TSO

ask Your support about the documentation for it

but ...
it could be a leftover of a prehistoric program product
OS TSO Data Utilities 5734-UT1.

providing the commands
COPY, FORMAT, LIST, MERGE.

it was known to buggy ( BTDTGTTS )
for example putting odd sequence numbers even when not needed/asked for

( BTDTGTTS ) Been There Done That Got The T Shirt
Back to top
View user's profile Send private message
Senthilkumar k
Warnings : 1

New User


Joined: 07 May 2009
Posts: 51
Location: Chennai

PostPosted: Mon Apr 20, 2015 3:25 pm    Post subject: Reply to: Issue with copying PDS members to another PDS
Reply with quote

Thx for the reply. If COPY is not an command then could you please let me know which command i can use to copy the pds members to another pds?
Back to top
View user's profile Send private message
Senthilkumar k
Warnings : 1

New User


Joined: 07 May 2009
Posts: 51
Location: Chennai

PostPosted: Mon Apr 20, 2015 3:41 pm    Post subject: Reply to: Issue with copying PDS members to another PDS
Reply with quote

Thanks guys. I have used SMCOPY which worked.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10203
Location: italy

PostPosted: Mon Apr 20, 2015 4:33 pm    Post subject: Reply to: Issue with copying PDS members to another PDS
Reply with quote

Quote:
hanks guys. I have used SMCOPY which worked.


using SMCOPY is a really bad idea
SMCOPY is/was no tmeant to ce a general purpose copy utility,
just an aid to deal with the TDSO SESSION MANAGER logs

hence the SM prefix
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 462
Location: The Universe

PostPosted: Mon Apr 20, 2015 5:12 pm    Post subject: Re: Reply to: Issue with copying PDS members to another PDS
Reply with quote

enrico-sorichetti wrote:
COPY is NOT a command provided by vanilla TSO

ask Your support about the documentation for it

but ...
it could be a leftover of a prehistoric program product
OS TSO Data Utilities 5734-UT1.

providing the commands
COPY, FORMAT, LIST, MERGE.

it was known to buggy ( BTDTGTTS )
for example putting odd sequence numbers even when not needed/asked for

( BTDTGTTS ) Been There Done That Got The T Shirt

I agree. The old COPY command was (is) known to be very buggy, along with most of the TSO Data Utilities package. The problem you had is a known issue. You can (usually) work around it by specifying the NONUM keyword. Otherwise, copying a single member from one PDS to another PDS usually works OK.

If the target PDS exists, you can use

REPRO input(member) output(member)

which should work on all systems unless the member is a load module, when it won't work
Back to top
View user's profile Send private message
Senthilkumar k
Warnings : 1

New User


Joined: 07 May 2009
Posts: 51
Location: Chennai

PostPosted: Mon Apr 20, 2015 5:34 pm    Post subject: Reply to: Issue with copying PDS members to another PDS
Reply with quote

Thank you very much steve-myers. I have used REPRO as you said and it is also working perfectly(even for load module).
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 462
Location: The Universe

PostPosted: Mon Apr 20, 2015 8:09 pm    Post subject: Re: Reply to: Issue with copying PDS members to another PDS
Reply with quote

Senthilkumar k wrote:
Thank you very much steve-myers. I have used REPRO as you said and it is also working perfectly(even for load module).

Just because it said it worked, don't bet on it. Load modules require surprisingly complex processing beyond just copying the data, and I'm not sure IDCAMS does it.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Mon Apr 20, 2015 8:53 pm    Post subject:
Reply with quote

It would be more appropriate to use IEBCOPY to copy members from one PDS/PDSe to another - particularly load modules(PDS)/program objects(PDSe).

If a load module is being copied, IEBCOPY will invoke the linkage editor/binder if required. This will always occur if copying from PDS to PDSe or vice versa in order to convert load modules to program objects or program objects to load modules (if possible), respectively.

IEBCOPY will provide error messages where necessary.

Garry.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 462
Location: The Universe

PostPosted: Mon Apr 20, 2015 11:24 pm    Post subject:
Reply with quote

Garry Carroll wrote:
It would be more appropriate to use IEBCOPY to copy members from one PDS/PDSe to another - particularly load modules(PDS)/program objects(PDSe).

If a load module is being copied, IEBCOPY will invoke the linkage editor/binder if required. ...
As far as I know, IEBCOPY copies load modules from PDS to PDS all by its little self, even if doing a COPYMOD to reblock a lod module. It does use the Binder when copying a load module to a PDSE.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Tue Apr 21, 2015 12:12 am    Post subject:
Reply with quote

@Steve-Myers: Yes, and from PDSe to PDSe all by its little self. - which is why I mentioned "if required", PDSe to PDS also requires invoking the linkage editor/binder.

Garry.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 462
Location: The Universe

PostPosted: Tue Apr 21, 2015 6:20 am    Post subject: Re: Reply to: Issue with copying PDS members to another PDS
Reply with quote

steve-myers wrote:
... If the target PDS exists, you can use

REPRO input(member) output(member)

which should work on all systems unless the member is a load module, when it won't work


I goofed. It should be -

REPRO INDATASET(...) OUTDATASET(...)

There are acceptable abbreviations for INDATASET and OUTDATASET.

I did try copying a load module, something I never did before. Unless the issue has been corrected in the last 10 years or so, IDCAMS screwed up big time, and that has other implications.

IDCAMS did not copy the directory user data. Without the user data, the member is not a load module and cannot be used as a load module. You can load the member into the Binder. It will complain and you lose some functionality, but the basic data within the load module will be usable.

After I discovered REPRO did not copy the directory user data for a load module I decided to try it with a member that has ISPF directory stats. Sure enough it did not copy the ISPF directory stats.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Apr 21, 2015 12:35 pm    Post subject:
Reply with quote

Well, IBM created IEBCOPY and saw that it was good.

Or was there maybe another reason, I don't see?
Back to top
View user's profile Send private message
Ramsee

New User


Joined: 06 Jan 2011
Posts: 52
Location: Chennai

PostPosted: Fri Apr 24, 2015 12:14 pm    Post subject:
Reply with quote

Using IEBCOPY you can copy members from PDS to PDS as well as it will Compress the unused Tracks and Cylinders of the output PDS to avoid space issues.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CLIST & REXX All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts DFHRESPONSE returns issue divated CICS 3 Wed Nov 02, 2016 6:32 pm
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm
No new posts REXX Screen not working due to LINKED... sundarkudos CLIST & REXX 1 Mon May 09, 2016 1:44 pm
No new posts Single step utility for compare and u... ramprakashn JCL & VSAM 5 Fri Apr 29, 2016 3:43 pm
No new posts Issue in sending zip file as mail att... ajithajt JCL & VSAM 8 Thu Apr 07, 2016 9:11 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us