Hi Dan
Seems this could be handled using a child release - or branch, it might be called. Turnover has that concept, I'm sure Implementer does - the git stuff certainly does. Then you decide in whatever tool you're using, you decide which objects need to be in the child - no need for special type codes (the Turnover term for object types). Each child or branch can have its own rules about authority needed and all.
Of course, I don't use Implementer, I just expect the big3 or big4 of the traditional software change management tools to be pretty close in function.
Cheers
Vern
On Mon, 15 Jul, 2024 at 10:05 AM, Dan Bale <dan.bale@xxxxxxxxxxxxxxxxxxxxx> wrote:
To: midrange systems technical discussion
The PFE and LFE are object codes I would duplicate from the PF and LF object codes. PF & PFE will be identical except by name; ditto for LF & LFE.
The reason: Our "normal" production library has thousands of data file objects. We are creating a new "extremely limited access" production library SECURELIB that will contain ~600 of the same object named/typed files. SECURELIB will be higher in the LIBL than our "normal" production library for privileged users. I want to convert the object codes for these ~600 objects to PFE and LFE. Object codes PF and LF would then be disabled for SECURELIB's environment (SECURELIBE). SECURELIBE would be added to the existing production environment group. The absolute key requirement is that objects that belong in SECURELIB would *always* be promoted to SECURELIB and the "normal" production library, and objects that don't belong in SECURELIB would *never* be promoted to SECURELIB but only to the "normal" production library. We don't want to rely on developers remembering which objects belong in SECURELIB.
- Dan
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>> On Behalf Of Therrien, Paul via MIDRANGE-L
Sent: Saturday, July 13, 2024 6:54 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>
Cc: Therrien, Paul <ptherrien@xxxxxxxxxxx<mailto:ptherrien@xxxxxxxxxxx>>
Subject: RE: MKS / PTC Implementer question: converting object codes
I don't have an answer to your questions, but we run Implementer at our company.
I don't' know what PFE and LFE object types are. Can you explain? They are not in the standard object code list. Are these a custom version of database types?
Outside of having implementer, how would you do this project?
I'm think you would probably create a new production data library for the new objects, copy the data to the new library and add the library into your jobd library lists above the current production data library.
And then with Implementer, create a new environment using the new data library.
Not a complete answer, but perhaps a starting point.
Good luck.
Paul
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx>> On Behalf Of Dan Bale
Sent: Friday, July 12, 2024 9:45 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx<mailto:midrange-l@xxxxxxxxxxxxxxxxxx>>
Subject: MKS / PTC Implementer question: converting object codes
This post is very Implementer specific. If you do not use or have never used Implementer, you may want to skip this post. (I reference MKS because many Implementer users never realized that PTC bought out MKS years ago.)
"For reasons", I need to duplicate the PF and LF object codes to PFE and LFE object codes, respectively, then convert hundreds of existing objects defined with the PF and LF object codes to PFE and LFE object codes. PTC provides articles 127578 "How to convert existing object from one object code to another in Implementer" (which doesn't apply to data files, but has relevant information) and 120120 "How to convert traditional DDS file to SQL DDL files in Implementer" (which is somewhat misnamed, since it also discusses the PF/LF to PFE/LFE type conversion as well). Those of us familiar with this process may remember that part of the process of converting data file objects requires creating a backup of the "live" data, wiping out the "live" files, promoting the files with the new object code, then copying back the data to the "live" files from the backup. Fine to do in a test/QA environment, not so much in a 99.99999<
http://99.99999>% uptime SLA production environment when dealing with hundreds of
large files.
Has anyone found a way to do this without taking production data files offline?
- Dan
*** CONFIDENTIALITY NOTICE: The information contained in this communication may be confidential, and is intended only for the use of the recipients named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ***
midrange.com
