RTC 3.0.1 - z/OS - Build Maps - Time Stamp field
The time stamp field is displayed in a format that is not easily decipherable - here is an example -- 1314902877000. Is there a way to convert that filed to what you would normally see when viewing an entry on a z/OS PDS?
|
10 answers
Hi
This is a UNIX based timestamp. Your question is vague.... yes there are ways to convert this to a more readable format. Here is a web site that does it... http://www.onlineconversion.com/unix_time.htm There are also ways in Java to do this... for example long unixTime = Long.parseLong(input); java.util.Date d = new java.util.Date(unixTime); I'm not sure without looking what format is used in a PDS but hopefully this is enough to go on. Guy |
Hi So when a specific UNIX time from a buildmap is converted to a more readable format will it be the same as the time stamp (last update) on a PDS entry. In other words will it match the "Last Update" time on a PDS member that was created as output. Maybe a better way of asking is - "How can I match a buildmap output member to a specific PDS member?" I can match a member name and a PDS name but not size or date/time. |
|
Hi
For a source member what you say is correct. We reformat that AIX timestamp and place it in the Last Update field that you can see. For a load module what we use is the SSI area. This is a 4 byte field that we place the binary representation of that timestamp into. Guy |
Hi Thanks |
Hi I would recommend RTC changing the buildmap timestamp format to be consistent with it in PDS. In PDS the Last Update Filed (Change) is shown like "2011/09/20 04:58:09" and the SSI filed is shown like "4E683598". Simple change can make buildmap more friendly. This also requested by one of my RTC customer. |
|
Hi
The format we have in the buildmap allows it to be quickly compared against other timestamps of the same format. We do comparisons during various operations like promotion. Storing the timestamp in either of the two PDS formats would mean we would have to convert before comparing and we don't want the performance hit involved with that. If you want to pursue this further I would recommend you open an enhancement request up for this as mentioning it in a forum post will probably means this just gets lost in the ether. Guy |
Hi I think the internal format of build map should be kept the same as is. But the timestamp in the buildmap report automatically generated and attached in the external link tab of build result can re-formatted to be human readable. Do you agree that? |
|
Hi Joseph
Nice idea..... although the link is actually to the buildmap itself, what happens when you click that link is the content of the buildmap is returned to us via a web service and then it is formatted for the browser. It may be possible to tweak the CSS we are using to reformat the timestamp into a human readable form. An alternative is for us to look at storing a human readable version of the timestamp in the buildmap as well as the storing it in the current format. The next step for you is to open an enhancement request with these ideas and we can triage it. I could open it for you but having someone external (a customer) open the request up tends to give it more weight when we are deciding what to implement. Guy |
Hi Joseph I created an Enhancement -- 180271. I think it's easy but valuable enhancement. |
Hi Joseph I created an Enhancement -- 180271. I think it's easy but valuable enhancement. |
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.