RSTOBJ restriction

[redvan]

I'm at a place where there is 2 main environments; DEV and PROD, like most shops.

PROD has a restriction where no one can use RSTOBJ, for obvious reasons, and we use TurnOver to move stuff into production.

I create many, many commands and utilities on DEV and sometimes wish I had them on PROD to perform tasks and such.

Is there anyway to get source members from one machine to another without using SAVOBJ and RSTOBJ?


I just had a revelation;
I think I have discovered a way to accomplish my task.
I'm going to download each component to a .txt file on my pc, then upload them to the other machine, unless there's an issue with FTP.

[tomholden]

Re: RSTOBJ restriction

I'm at a place where there is 2 main environments; DEV and PROD, like most shops.

PROD has a restriction where no one can use RSTOBJ, for obvious reasons, and we use TurnOver to move stuff into production.

I create many, many commands and utilities on DEV and sometimes wish I had them on PROD to perform tasks and such.

Is there anyway to get source members from one machine to another without using SAVOBJ and RSTOBJ?


I just had a revelation;
I think I have discovered a way to accomplish my task.
I'm going to download each component to a .txt file on my pc, then upload them to the other machine, unless there's an issue with FTP.

you're best bet is to put these through change management. then you don't have to worry about all of the workaround stuff. not to mention when auditors find it and wonder why it's there with no auditing/tracking you won't get slammed for it. an ounce of prevention is far better than a pound of cure...

[MichaelCatalani]

Re: RSTOBJ restriction

Is there anyway to get source members from one machine to another without using SAVOBJ and RSTOBJ?


I just had a revelation;
I think I have discovered a way to accomplish my task.
I'm going to download each component to a .txt file on my pc, then upload them to the other machine, unless there's an issue with FTP.

The short answer is, yes there is. However, these should also be locked down in the production environment if your security has been set up correctly.

The long answer is, just because you can do something doesnt mean you should do it. Clearly your production environment is locked down, as it should be. Before putting any application / tool in production, you need to make sure that the person responsible for that environment agrees that you can load it. You still want to use turnover so that any changes to these tools can be made and tracked through your change management software. If you use turnover, then the person in charge of promoting objects into production will know what you are doing.

The last thing you want to have happen is that one of these tools wipes out data or brings down the production environment for some reason, and noone above you even knew you had done this.

In other words, cover your @#%@#%@#% with an iron man hole cover.

[redvan]

Re: RSTOBJ restriction

Gentlemen,
I fully understand your concerns and the need for the paper trail.

In a previous life, my manager had no objection to moving programmer-made utilities to Production through CMS and then TurnOver AFTER he had given all the components a once over, just to be sure there was nothing related to the argument we had 3 days ago that would shutdown the system sometime in the near future.

Here, each programmer has their own library on PROD and are free to do "things" as needed (if the auditors only knew!).

Since programming on PROD is not frowned upon and often encouraged, in a time of need, there will be no repercussions from my clandestine maneuvers.

The utility I want to move over has a CMD, several PNLGRP's, several RPG's, a RPGLE, a DSPF......
Far more than I am willing to "re-create" on that box.

My revelation worked and in less than 15 minutes, had my utility.
Thanks for your support, concern and assistance.