It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×12,008
×562
×123
×14

question asked: Apr 11 '13, 5:10 a.m.
question was seen: 6,105 times
last updated: Jun 13 '13, 9:31 a.m.

Related questions

RTC IBMi Builds - How does it decide what is a changed item?

0
James Cole (95●3●26●30) | asked Apr 11 '13, 5:10 a.m.
retagged Apr 18 '13, 12:51 p.m. by Kevin Doyle (604●2●5)
Hi All,

In version 3.0.1 I have created an IBMi build definition to load latest changes. Upon reviewing the logs I can see 3 common options in the log.

1) No object found - need to build.
2) Object not up to date - need to build
3) Object is up to date - no need to build.

Therefore my question is how does it determine if the object is up to date. Is it done by timestamp, binaries or another method? 

Has the process changed in version 4, if so how?


Many Thanks 

James

3 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
jeff tickner (51●7●10) | answered Apr 11 '13, 9:09 a.m.
 what kind of build definition specifically? a build specification?
If you said load latest changes during the build the stream is compared to the build workspace and any member new or changed in the stream is part of the build.
I don't understand the reference to 'object' in your post, can you elaborate?
Thanks

Jeff Tickner
Comments
James Cole commented Apr 11 '13, 9:37 a.m.
Sure no problem Jeff.

Yes at 3.0.1 I am using an IBMi Build specification, which contains all the builders and command sets etc.


When I select load latest changes it appears to push just the changed source down. However, it appears to scan every source member in the source file to compare with the output of the object. 

For example, I have a source file that contains a 1000 source members and I change 3 inside RTC. RTC will push down the 3 changes on load latest change sets, but scan a 1000 members to compare the source and objects to decide what is built, not just the 3 I changed. The log indicates one of the 3 options I mentioned earlier. 

Hope this clarifies the question.

0
permanent link
Kevin Doyle (604●2●5) | answered Apr 18 '13, 12:50 p.m.
JAZZ DEVELOPER
IBM i Build Specification builds determine what to build after doing the loading by doing timestamp comparisons, so it checks every member against the object.  Based on what it determines needs to be rebuilt it determines what other objects need to be rebuilt based on the dependency analysis and the information provided in the build specification.

This has changed in 4.0 as the IBM i Build Specification has been deprecated in favor of the IBM i Dependency Build definition.  With this new style of build definition we no longer do timestamp comparisons unless you turn that option on.  We instead rebuild the members we load and any dependencies that have been detected that need to be rebuilt based on those members.
Comments
James Cole commented Jun 13 '13, 5:57 a.m.

HI Kevin, 


Thanks for this. Please could you clarify the IBM i Build specification builds timestamp comparisons. Is it based on the source member changed date or created date, against the object etc or some other timestamp? As it scans the whole source file I want to make sure the results I get are what I should expect.

I know that the library list needs to be set correctly to find the latest object that you would expect to find.

Many thanks

James

Kevin Doyle commented Jun 13 '13, 9:31 a.m.
JAZZ DEVELOPER

Hi James,

We compare the time of the member (last changed on the IBM i system) against the object that we determine would be built based on that member from the Build Specification.  If the members time is newer then the object we will rebuild it.

The first step of the build is to load the source, so the member times are updated on the IBM i based on that and then we do the time comparisons.

0
permanent link
jeff tickner (51●7●10) | answered Jun 13 '13, 9:09 a.m.
 James, even though Kevin used the term object I think he meant member. I'm pretty sure the build never looks at objects in the build library or library list for change information.
I don't think the create date and change date in RTC can be like they are in IBM i where the change date can actually be older then the create date.
I would say that RTC is always looking at change date as if you look at the properties of a member in the stream it just has one timestamp field which is change date based on the properties of the member in the iProject where it matches the last modified field.

Jeff Tickner
Arcad Software

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.