Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Create a package whose objects can't be transported???

Former Member
0 Likes
788

Hello all,

We are planning on deleting a number of customer programs that have become obsolete. Before we delete these programs we plan on copying them to a new package. We do not want any of the objects that are created within this new package to be transported out of our development environment. Is there a way to accomplish this systemically rather than depending upon discipline?

Is this a situation anyone has experienced and do they have a solution?

Thanks

Bruce

6 REPLIES 6
Read only

RichHeilman
Developer Advocate
Developer Advocate
0 Likes
760

When coping them, you can assign them to $TMP development class(package). This will keep them local. You could also create a custom or "Z" devleopment class(package) which is not transportable.

Regards,

Rich Heilman

Read only

0 Likes
760

When creating a development class(package) for local objects, it must begin with $. So if you want to create a custom DC, start with $Z. Don't enter anything for transport layer and use LOCAL for the software component.

Regards,

RIch Heilman

Read only

0 Likes
760

Rich,

Thanks for your answer. I took a different approach. These are the values of the parameters I set when creating the new package:

Transport layer - I left this blank

Software component - Home

I set the software component to home instead of local because I wanted a transport request to be created. This will allow better auditing as well as prevent multiple users from editing the same object once the object has been assigned to a development request.

I set the transport layer to space to prevent the development request from being transported.

Thanks

Bruce

Read only

0 Likes
760

Your approach will work Bruce. I am assuming that you are going to <b>copy not reassign</b> each of the obselete custom objects. Copy them to a new program that is assigned to this new development class and kept in a transport request.

The reason for copying instead of reassigning is that once you are ready to delete the obsolete objects from your production system, you need to send a transport deleting them to production. If you just reassign, you will not be able to transport it and delete the objects in production.

Srinivas

Read only

0 Likes
760

Srinivas Adavi,

Yes, we will be copying these programs to the new package, adding the suffix "_OBS" to the program name. After we've copied the program, we will delete the original.

Thanks

Bruce

Read only

Former Member
0 Likes
760

closing old post