A Quick Tour of Ash Fork AZ

On the way to Saint Johns, Arizona where I have family, we took some time to browse the town of Ash Fork, Arizona.  Ash Fork is the flagstone capital of the world.  It began as a railroad town in 1882. It got its named from the fact there were a bunch of ash trees growing in the area. In 1926, Route 66 came through Ash Fork and remained a town on the route until 1979 when Interstate 40 bypassed the town.

Lois provides a lot of the descriptions and commentary in our tour video.

UP NEXT:
A drive through downtown Williams AZ and arrival at Saint Johns AZ.

Customized code upgrade remediation speed bumps

 One of the things I do in my IBM i career is apply vendor-updated "vanilla" source code to client-customized code.

The process is fairly straight forward:
For each client-custom version of a program that received an update from the vendor, compare the two versions, apply vanilla updates to the client version, keeping the customization intact. 

Many years ago (think dinosaur age), you would have to create two lists from DSPOBJD (the client-customized objects from a library higher in the library list than the vendor's application library, and the vendor supplied objects within their upgrade library).  You would look at the two lists to find matches and identify source locations of each object. Then you would use CMPPFM to generate a report to show the differences between the source members.

I'm very glad we have moved far from those old methods.  Today, using the Code for IBM i extension in Visual Studio Code, you can quickly work from filtered source lists, performing comparisons and see differences side by side, and often times just click sections of code to include from one side to the other.  If you are a good programmer, it is a little more complex than that because you are analyzing what the code does so that you don't inadvertently break functionality if there is tightly knit custom code around the upgraded code.

For one of my recent projects, I found myself in the twilight zone where my hands were partially tied in the methods I could use to perform the required remediation work.  For a bit there, I was beginning to get worried that I had fallen down the deep hole of history back to the CMPPFM days.  Fortunately, I didn't just throw my hands up and accept doing things the very old way.  But it was an interesting journey to accomplish the task. The tools I had to work with were any of the old 5250 "green screen" PDM tools with SEU; Visual Studio Code WITHOUT the Code for IBM i extension; and ACS Schemas, IFS Browser, and Run SQL Scripts.

The first step was to identify which customized objects were included in the upgrade.  Fortunately, the source code resided in the same libraries as the customized objects.  In the Test environment, there was a Mod Test library that sat above the Mod Prod library in the library list, so the Mod Test library only contained changed objects being tested, not yet part of production code. Data libraries kept Test and Production completely separate in the environments. The vendor provided upgrade provided source in three libraries.  These were a hierarchy based on when the code was modified.  Even though it was one upgrade release I was dealing with, it was provided somewhat like a fix, then more fixes and fixes to earlier fixes, while maintaining the upgrade release as one entity. As such, a matched source may or may not exist in any one or more of the three source libraries provided by the vendor.  That becomes a bit more complex, and again, I was so glad I didn't have to completely fall back into the dinosaur age.

Now we get to the real meat of this post. Using ACS Run SQL Scripts, I constructed a Select statement to identify which customized members were included in the upgrade and which vendor provided libraries contained the upgraded vanilla source.

The first half (WITH MbrFlags) identifies customized source, whether it is also in the upgrade, and which upgrade libraries the source member is in.  The second half presents each customized source having a matched upgrade member, some information about that source member, and within which upgrade release libraries that source member exists.

The result was a huge time saver!  Half the battle was won by identifying the scope of which members required remediation.

The next step was to perform the source comparisons. Even though there was no way for me to connect VS Code to this specific IBM i system, I was determined to use its side by side compare function to edit the customized source.  Getting the source from file members on the IBM i to text files on the PC was by far the most time consuming. I'm not sure now how I landed on the method I did.  There were probably a couple possible methods.  I ended up using the IFS Browser to drill down to /QSYS.LIB/source_library.LIB/Q_source_file.FILE/member_name.MBR for each of the source members I needed to deal with, from mod libraries and upgrade libraries, downloading each to an appropriate folder structure on the PC for organization.

Once I had all the relevant source on the PC, using VS Code, I opened the customized source folders to work from their list of source files. Going down the list, I opened one, then opened the appropriate upgrade source version based on the result from the SQL above.  Performed the Select for compare and Compare with selected options producing the side by side comparison.  Then it was a simple matter of editing the custom version with either copy/paste or clicking the arrow in the center gutter.  Save the updated source and repeat for the next customized source in the list.

After all the edits were complete,. I had to get the modified source back to the IBM i.  For this step, I used the Send Files tool within the 5250 terminal.  I created a new library to receive all the remediated source. I uploaded all the remediated source into this library.  This took a while again to perform the transfers.

Once all source members were back on the IBM i, I was able to set my library list appropriately, and compile all the remediated source into new objects for testing.

Paulden Arizona

 We got the tire replaced on the side of the road at Exit 71 on I-40 East of Kingman Arizona very late at night on Saturday, May 30th. From there we made our way to our sister-in-law's house in Paulden, AZ to spend the rest of the night. In the morning we assessed other damages.  Not terribly bad, but certainly annoying. The flying tire tread ripped the wire out of the driver-side camera and whacked the high beam headlight hard enough to necessitate replacement. I spoke with Rick, a friend in the area. He thought he might have a replacement headlight among his parts collection. As it turned out, he did not. However, that will be an easy Autozone item to pick up.  We'll be making our way to St Johns Arizona next with a quick tour of the town of Ash Fork on our way.

Getting on the road

 Memorial Day week was a busy week starting off with Memorial Day (imagine that).

We attended the Field of Honor ceremony honoring fallen service members at Cornerstone Park in Henderson, NV.  Over 500 American flags were placed as a symbol of patriotism, pride and reverence..  Remarks were given by the Henderson Mayor Michelle Romero, Congresswoman Dina Titus, Councilwoman Carrie Cox, and others.  The event concluded with a bugler playing Taps.

The registration on the motorhome was coming due in June, but since we would already be on the road at that time, we had to take care of the smog test and registration renewal during the week.

We did our best to stage everything to go on the trip in the guest room. It has been very annoying to be on the road and suddenly realize a particular item or in most cases multiple items forgotten at home. We did the best job to date, but alas, we still forgot something - the basket of Minnie's toys. We'll be getting her some more while travelling.