Check-in Help

jenningp

Member
I’m pretty new to Oneworld (have only been involved with the product for a month or so) and am now taking on the CNC and admin responsibilities for the product. Site is currently on B733.2 SP9 and has no in depth OW CNC knowledge. Our enterprise server is an AS400 720, which hosts our central objects and we use simple FAT clients. Recently, after having numerous problems with our production environment, we commissioned a consultant to re-build and re-deploy our live environment. This was successful and completed without and problems. However our DEV, TEST AND CRP environments are still in the same state as our live environment was. My aim is to retrofit PRD733 to the other environments (copy PRD733 over CRP733 etc) so as to give us a consistent and reliable base for future development. I have a good idea of how to achieve this, however, my instructions suggest making sure all objects in PRD733 are checked in before I proceed. After some time I managed to work out how to find out the check-in status of our objects and discovered and number of objects checked out. With no change control procedures in place I am having difficulty tracing our checkouts and believe that some of the info is spurious. Is there any way to force check-ins or otherwise fool the environment into thinking there are no objects checked out?

Any information would be much appreciated.

Thanks in advance (from a beginner)

Paul
 
Paul,
How many people have the ability to check out objects? (You could run a
security report to see this). Checking out objects should be something
that very few people have rights to (only developers).
Once you find out the individuals who do have rights to check out -
speak with them and have them check the objects back in. Then of course
you will want to implement a change control process as soon as possible!

Lisa G. Stinebuck
Senior Service Delivery Technician
Logical eBoc
US Logical
311 Elm Street, Suite 150
Cincinnati, OH 45202
(513) 412-3400 Office
(513)378-2832 Cell
[email protected]
www.us.logical.com <http://www.us.logical.com/>
 
Hi Paul,

First of all you are welcome aboard!

How did you work out the check-in/check-out status of your objects?
Based on the F9861 "Object Librarian - Status Deatail" or on F9882 "Checkout Log Table" or on a combination of both or using any OW APPL/UBE like P9882 or R9882000?

Unfortunately, existance of a check-out entry in F9861 does not necessary mean that the effected object have to check-in. There are three typical scenario of it:
1.) The reason of check-out was to "fast install" a modified and checked-in object onto the workstation. In my honest opinion, the best habit is to erase the check-out entry immediately in this case. Not too nice to keep the check-out if the reason was only a "fast install".
2.) Somebody wanted only to investigate an object with its designer. Also good habit to erase check-out after she/he is finished with that job. Best habit, to erase immediately and creating "fake" check-out when I want to open the object with its designer.
3.) Somebody wanted only to experimeting with an object but does not want to preserve the changes. The best habit is the same as I de[censored]d at 2.)

Also not necessary to check-in an object when it was checked-in after the last modification but kept in check-out and no further modification happened after that check-in.

Not an easy job to keep order the Object Librarian when too many user have check-out rights in OneWorld.

My last suggestion:

Extract the check-outs from F9861. Once grouped by User/Workstation/Object once grouped by Object/User/Workstation.

Send the list to the involved users asking them:
1.) Why are those check-outs?
2.) Please, erase it when... (see scenario 1,2,3)
3.) Please, check-in your last modification when it is necessary to preserve it and erase your check-out.

BE CAREFULL when an Object has more than one check-out!

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 
Oneworld does not provide a way through the application to do the type of things your asking. You must go to each workstation if you want to check in the objects. You cannot force a Check-in.

Using SQL you can clean up the tables but you must be very careful you can really get into trouble very fast.

Also remember that Versions are handled separately from other objects.


1. For OBJECTS that have never been checked-in but you want to keep you must have them checked in from the machine shown in the SIMKEY field in the F9861 table.

2. You can identify Objects that have never been checked in by identifying objects in the F9861 table that do not have an entry where the SIMKEY field contains the name of your DEPLOYMNET SERVER for the PATHCODE in question.

3. For VERSIONS the workstation is the VRMKEY field.

4. You can identify VERSIONS that have never been checked in if the VRVRASVAIL is ‘N” for the PATHCODE in question.

If you decide to clean up the checkouts using SQL: (AGAIN BE VERY CAREFUL)

6. For OBJECTS that have never been checked in you need to delete records from both the F9860 and F9861.

7. For VERSIONS that have never been Check in you need to delete records from the F983051 for that version and pathcode.

8. For OBJECTS that have been checked in at least once and you have determined that you don’t want to save changes that might have been made by the user you can erase the checkout by deleting the records for the objects in question from the F9861 for the PATHCODE in question.


9. For VERSIONS that have been checked in at least once and you have determined that you don’t want to save changes that might have been made by the user you can erase the checkout by changing the F983051. Change the VRCHKOUTSTS field to ‘N’ and the VRMKEY field to your DEPLOYMENT SERVER name.


This takes care of the prod pathcode but you need to think about the environments you are coping to. If you are doing any development you will wipe out any work that has not been moved to Prod. You will also need to clean up Object librarian for the other environments or you will have ghost records.


I must stress again that you must be sure of what you are doing if you choose to use SQL.




Mike Trottier
Independent CNC Consultant
Onsite and Dial-up Support
B731,B732,B733,XE
AS400,Unix,NT
Oracle,SQL
#801 557-8368
 
It’s only a small financials deployment (that runs along side an older ERP suite) but I believe all users have the ability to create and modify UBE's and associated versions. The problem is further compounded in that much of this work has taken place in our live environment. The company who initially were involved in the deployment of the product were very lax and not particularly knowledgeable or professional. I’m now trying to find my feet and pick up the pieces.

I did manage to work out what objects were checked out and managed to get them checked back in again. Some of the checkout's were spurious and some were never likely to be checked back in again. For both of these I used the erase checkout function in OL. This seems to have tidied things up considerably. A look at security and development issue's will be my next point of focus I think.

Thanks for your help
 
jenningp,
no problem. A while back I found myself in the same situation when I
took over as CNC/Admin of OneWorld for a company - I feel your pain!
Nothing was documented and users where just using the software - they
had no clue how it actually "worked" (at the time - since then they have
come full circle).

I found it best to use security and tighten it down such that users
could check things out but could not check things back in without going
through the admin. This helped so-o much in being able to document
change control and to keep CRP and PROD in sync with each other. You
might want to consider something like this.

Lisa G. Stinebuck
Senior Service Delivery Technician
Logical eBoc
US Logical
311 Elm Street, Suite 150
Cincinnati, OH 45202
(513) 412-3400 Office
(513)378-2832 Cell
[email protected]
www.us.logical.com <http://www.us.logical.com/>
 
After the consultant cleaned up your "live" environment did you deploy a full package to all workstations?

If you did, any changes made to objects checked out on the workstations before the package was deployed are lost anyway.

Dave.

David D. Helsley, Inc.
[email protected]
Xe, Unix Sp16.1, Oracle/MSSql, TSE
 
Yes he did. We were well aware of this but our system was in such a mess that we decided it was a necessary move. For instance developers (outside consultants) had checked out objects from our environment and had left the company they were working for. We decided to take a hit and make a clean start. Most of this work that was paid for and never delivered (and was never likely to be delivered) i.e. may still be residing on our old consultants laptops. We now have a clean PRD environment and workstations that function. We recovered as much development work as we possibly could before doing this.

Cheers
 
Thanks. Your overview seems pretty definative. I was aware that direct sql intervention would allow me to bypass OW application rules but did not want to attempt this due to my inexperience with the product. By the way are there any sources of info that detail the exact use of tables involved in the CNC side of OW or is this something that will come from experience with the product? Im currently using the complete reference and an IBM redbook on OW (pretty hard going).

Cheers
 
Try ordering the J.D. Edwards OneWorld: The Complete Reference. This
book is written by Joseph E. Mill, Allen D. Jacot, John A. Stern. The
ISBN for this book is 0-07-212510-1 The best I can remember this book
is about $50.00.

Lisa G. Stinebuck
Senior Service Delivery Technician
Logical eBoc
US Logical
311 Elm Street, Suite 150
Cincinnati, OH 45202
(513) 412-3400 Office
(513)378-2832 Cell
[email protected]
www.us.logical.com <http://www.us.logical.com/>
 
Back
Top