Tweet
NAB Import enhancement suggestions
We move apps from DEV -> QA -> PROD. DEV and QA are on the same LPAR, PROD is on another LPAR. Pretty typical set-up.
I'm in QA and I need to promote an app that's ready for install to PROD. This must be done with the save-file option. Intra-instance moves can only be done between instances on the same LPAR.
When I do the export>Save File deal, I get a pop up in which I can enter a Note. If I go to NAB import in any other instance on that same LPAR I did the export on, I can see that note in the Name column, just below the app's name. It shows some tags, too
nab import in 10.png
After I FTP the SAVF to the production LPAR and fire up NAB Import there, it does not show that note or the tags. I get that, because all there is in VVEXPORT is that SAVF and all you can scrape off of that thing is the SAVF object text and clearly that's what I see in the Name column. It would be nice if the note and the tags showed there too, but I understand that won't happen until we come up with some other mechanism to get these SAVFs from source to target... and the VVEXPORT.VVEXPORTS record with it. BUT... I do see a file in that SAVF called VVEXPORTSQ. And after I restore that and look at it, I can see my note and tags in there
Save File Name.... VVSAVF A221101790
Exported From Ins VVEXPFR SPACE6D10
Object Type.... VVEXPTYPE A
Exported ID...... VVEXPID 1001
Exported On...... VVEXPTS 2022-11-01-13.46.30.835749
Exported By...... VVEXPBY DRGADGET
Exported From Ve VVEXPVER 6.1.20221026.1
Last Imported VVLSTIMPTO
Last Import Ti VVLSTIMPTS 0001-01-01-00.00.00.000000
Last Imported VVLSTIMPBY
Description....... VVDESC Gadget
Export Notes...... VVNOTE Dr. Gadget was here
Tags.............. VVTAGS DP
I don't know what the purpose of VVEXPORTSQ is in that SAVF but if the intent was to update the local VVEXPORTS record with that, it's not happening. This is likely a bug.
Now for the enhancement suggestions.
1. NAB Import has 3 tabs, data sources, widgets and apps. It defaults to the Data Source tab. I'd wager to guess most people predominantly export apps. We certainly do. It would make a lot more sense if NAB Import would default to the apps tab.
2. These tabs are a bit.... non-descript. They look more like column headers than tabs. Portal tabs look a lot more like tabs. I would much prefer these NAB import tabs looked more like portal tabs. Not as ginormously wide and with more separation between them. Alternatively, ditch the whole concept of tabs there and come up with something else to select data sources, widgets or apps.
3. Whenever I go to NAB import to import an app, 99.999% of the time I want to work with an export file I just created. Or at least very recently. Thus it is hard to understand why these things are sorted by create-timestamp ascending. My list of save files there is no so long that scrolling to get the bottom has worn out my mouse wheel and so now I have to sort every time on Date. It's not a big deal but it just gets old, having to get to the right tab all the time and then having to resort the screen to see my SAVF
4. As noted earlier, after you do an export>Save file in some instance and you then go do that NAB import, either in the same instance you just did the export in or a different instance on the same LPAR, the data you see in NAB Import is the same. That makes sense and I get it, it's just data from the same VVEXPORTS file in the same VVEXPORT library. But the problem is that I have absolutely no idea which instance that export was done in. I have no idea if that export save file came from DEV or QA. we need to add from-instance name to VVEXPORTS. And that really should not be that hard, I see several good candidates in VVSETTINGS, like, APACHE_INSTANCE_NAME.
Actually, I see that field is already in VVEXPORTS! Field VVEXPFR. It just isn't displayed in the NAB import grid.
Unfortunately, unless we come up with some sort of mechanism to get the VVEXPORTS file on the PROD instance to reflect all the attributes, this is not going to help me much on the PROD box, and that is where it matters the most that I am importing an app that was exported from the QA instance and not from DEV. NAB import, when you select a SAVF you want to import, you get a pop-up showing you the guts of that thing. If you click the CONFIRM button, that thing is going to restore objects from that SAVE file and (I assume) update several VV physical files. I assume that that grid shown in NAB import gets its data predominantly from the VVEXPORT/VVEXPORTS file. Either that or it's just doing a DSPOBJD over VVEXPORT library and showing me what's there. My guess is it's doing a bit of both. If it sees a SAVF in VVEXPORT library that's not in VVEXPORTS file, it writes it.
How else would that record get there? I don't mean to solution here but just throwing out some ideas... at the time it decides to write a record into VVEXPORTS for that SAVE file it sees in VVEXPORT library, go and restore that VVEXPORTSQ file in that very save file and use that to write that record, including the NOTE, TAGS and EXPORTED_FROM_INSTANCE attributes.
5. Last import.
On my production box, those columns are populated. Shows me who, when and to which instance it was imported. I only have one instance on the production box so the imported-to-instance there is of limited value for me, but I understand we're looking at data from a shared file here and there could be other instances on that machine.
On my development box however, that column is never updated. Why is that? Because we don't to the export>Save File thing on the DEV box. Why would I when I can just move an app from one instance to another with instance>instance move. Evidently, when you do an instance to instance move, the to-instance is not being updated. The instance-instance thing *IS* creating SAVFs in VVEXPORT and is writing records to VVEXPORTS. So now I am not only looking at a long list of save files that I have no idea where they came from, I also have no clue which instance(s) they were imported into. Basically, I have no way of knowing what happened. Where did this app come from and how and when did it get here? Either we need more fields in VVEXPORTS, or. probably better, we need a VVIMPORTS file. The problem with VVEXPORTS being an LPAR file rather than an instance file is that the same SAVF can be imported into multiple instances and even if instance->instance was updating the VVEXPORTS record with that import event the same way the export>save file> NAB import method does, we would end up with that single record for that export SAVF being updated again and again. Thus, we have no traceability and that's why I am recommending a VVIMPORTS file that's more like a log file, an event file.
I have far more ideas but I've probably overstayed my welcome so let's start with this..
-gadget
I'm in QA and I need to promote an app that's ready for install to PROD. This must be done with the save-file option. Intra-instance moves can only be done between instances on the same LPAR.
When I do the export>Save File deal, I get a pop up in which I can enter a Note. If I go to NAB import in any other instance on that same LPAR I did the export on, I can see that note in the Name column, just below the app's name. It shows some tags, too
nab import in 10.png
After I FTP the SAVF to the production LPAR and fire up NAB Import there, it does not show that note or the tags. I get that, because all there is in VVEXPORT is that SAVF and all you can scrape off of that thing is the SAVF object text and clearly that's what I see in the Name column. It would be nice if the note and the tags showed there too, but I understand that won't happen until we come up with some other mechanism to get these SAVFs from source to target... and the VVEXPORT.VVEXPORTS record with it. BUT... I do see a file in that SAVF called VVEXPORTSQ. And after I restore that and look at it, I can see my note and tags in there
Save File Name.... VVSAVF A221101790
Exported From Ins VVEXPFR SPACE6D10
Object Type.... VVEXPTYPE A
Exported ID...... VVEXPID 1001
Exported On...... VVEXPTS 2022-11-01-13.46.30.835749
Exported By...... VVEXPBY DRGADGET
Exported From Ve VVEXPVER 6.1.20221026.1
Last Imported VVLSTIMPTO
Last Import Ti VVLSTIMPTS 0001-01-01-00.00.00.000000
Last Imported VVLSTIMPBY
Description....... VVDESC Gadget
Export Notes...... VVNOTE Dr. Gadget was here
Tags.............. VVTAGS DP
I don't know what the purpose of VVEXPORTSQ is in that SAVF but if the intent was to update the local VVEXPORTS record with that, it's not happening. This is likely a bug.
Now for the enhancement suggestions.
1. NAB Import has 3 tabs, data sources, widgets and apps. It defaults to the Data Source tab. I'd wager to guess most people predominantly export apps. We certainly do. It would make a lot more sense if NAB Import would default to the apps tab.
2. These tabs are a bit.... non-descript. They look more like column headers than tabs. Portal tabs look a lot more like tabs. I would much prefer these NAB import tabs looked more like portal tabs. Not as ginormously wide and with more separation between them. Alternatively, ditch the whole concept of tabs there and come up with something else to select data sources, widgets or apps.
3. Whenever I go to NAB import to import an app, 99.999% of the time I want to work with an export file I just created. Or at least very recently. Thus it is hard to understand why these things are sorted by create-timestamp ascending. My list of save files there is no so long that scrolling to get the bottom has worn out my mouse wheel and so now I have to sort every time on Date. It's not a big deal but it just gets old, having to get to the right tab all the time and then having to resort the screen to see my SAVF
4. As noted earlier, after you do an export>Save file in some instance and you then go do that NAB import, either in the same instance you just did the export in or a different instance on the same LPAR, the data you see in NAB Import is the same. That makes sense and I get it, it's just data from the same VVEXPORTS file in the same VVEXPORT library. But the problem is that I have absolutely no idea which instance that export was done in. I have no idea if that export save file came from DEV or QA. we need to add from-instance name to VVEXPORTS. And that really should not be that hard, I see several good candidates in VVSETTINGS, like, APACHE_INSTANCE_NAME.
Actually, I see that field is already in VVEXPORTS! Field VVEXPFR. It just isn't displayed in the NAB import grid.
Unfortunately, unless we come up with some sort of mechanism to get the VVEXPORTS file on the PROD instance to reflect all the attributes, this is not going to help me much on the PROD box, and that is where it matters the most that I am importing an app that was exported from the QA instance and not from DEV. NAB import, when you select a SAVF you want to import, you get a pop-up showing you the guts of that thing. If you click the CONFIRM button, that thing is going to restore objects from that SAVE file and (I assume) update several VV physical files. I assume that that grid shown in NAB import gets its data predominantly from the VVEXPORT/VVEXPORTS file. Either that or it's just doing a DSPOBJD over VVEXPORT library and showing me what's there. My guess is it's doing a bit of both. If it sees a SAVF in VVEXPORT library that's not in VVEXPORTS file, it writes it.
How else would that record get there? I don't mean to solution here but just throwing out some ideas... at the time it decides to write a record into VVEXPORTS for that SAVE file it sees in VVEXPORT library, go and restore that VVEXPORTSQ file in that very save file and use that to write that record, including the NOTE, TAGS and EXPORTED_FROM_INSTANCE attributes.
5. Last import.
On my production box, those columns are populated. Shows me who, when and to which instance it was imported. I only have one instance on the production box so the imported-to-instance there is of limited value for me, but I understand we're looking at data from a shared file here and there could be other instances on that machine.
On my development box however, that column is never updated. Why is that? Because we don't to the export>Save File thing on the DEV box. Why would I when I can just move an app from one instance to another with instance>instance move. Evidently, when you do an instance to instance move, the to-instance is not being updated. The instance-instance thing *IS* creating SAVFs in VVEXPORT and is writing records to VVEXPORTS. So now I am not only looking at a long list of save files that I have no idea where they came from, I also have no clue which instance(s) they were imported into. Basically, I have no way of knowing what happened. Where did this app come from and how and when did it get here? Either we need more fields in VVEXPORTS, or. probably better, we need a VVIMPORTS file. The problem with VVEXPORTS being an LPAR file rather than an instance file is that the same SAVF can be imported into multiple instances and even if instance->instance was updating the VVEXPORTS record with that import event the same way the export>save file> NAB import method does, we would end up with that single record for that export SAVF being updated again and again. Thus, we have no traceability and that's why I am recommending a VVIMPORTS file that's more like a log file, an event file.
I have far more ideas but I've probably overstayed my welcome so let's start with this..
-gadget
Comment