Saving with STG(*FREE)
I have a good "Gotcha," although this problem will probably be resolved in the new Release 3.0. A few months ago, my boss wanted to do Reclaim Storage (RCLSTG) and decided to do a system save after that. At one of the prompts, he opted for STG(*FREE); having come from the System/36, he thought *FREE was the equivalent of COMPRESS. Since there was no warning regarding this parameter, he went ahead and did it this way.
Well, it turns out that STG(*FREE) caused the system to delete everything that was saved, so we spent the whole day restoring. To you S/36ers, think of STG(*FREE) as a RETAIN-S of your entire system.
We did call IBM - they agreed that a warning will be issued about this parameter, and you have my boss to thank for it. All I can say is, I am glad it happened to him and not to me.
- Chris Hutchings
Note From the Editor:
As of Release 2.0, the help text for the STG parameter reads as follows:
Free Storage (STG)
Specifies whether the system storage that is occupied by the data portion of files, programs, and journal receivers in the library being saved is freed as part of the save operation. Only the data portion of the objects is freed, not the descriptions of the objects.
*KEEP The storage occupied by the data portion of the objects being saved is not freed.
*FREE The storage occupied by the data portion of the files (except for save files), programs, and journal receivers being saved is freed as part of the save operation. The storage for all the objects in a library is freed only after all the objects in that library are saved successfully.
Let me tell you a story that began about four months ago. We have a programmer assigned to resolve all problems that occur during our nightly run. One month-end, a job bombed because of an authority problem. I told the programmer to compile the object with adopted authority, that is, indicating USRPRF(*OWNER). That would correct the problem. Well, the next month the same program bombed for the same reason.
I questioned whether she had compiled the object with adopted authority, and she said, "Yes, I did." When I looked at the object with the Display Program command (DSPPGM), there was no adopted authority. After admonishing her for the mistake I told her to correct it and she compiled the program while I watched.
Lo and behold, the next month the same program bombed again, for the same reason. When I displayed the program, there was no adopted authority. Since I had seen her compile the object with USRPRF(*OWNER), I was stunned! I recompiled the program myself with adopted authority and displayed the program one more time but there was no adopted authority yet.
It turns out that the user authorities of this program had been changed and it adopted the earlier program's user authority and disregarded the compile options (as I found out in the joblog).
Talk about a "Gotcha!" This one made me look like a fool for yelling at a programmer who did what I said, and took me weeks' worth of time to resolve, mostly because we did not maintain joblogs on jobs that finish normally. All of you, please beware...
- Tom Harper
Note From the Editor:
Is there a moral in this story? Could it be that, even as much of a nuisance as they are, joblogs are worth looking at after all?
Customizing Your Sign-On Display
The AS/400 Sign-On display can be easily customized since IBM provides the source code in source file QDDSSRC, library QGPL. The member to look for is QDSIGNON.
Shortly after starting work on my first AS/400, I decided that I had had enough of the standard Sign-On display, so I set about modifying it. Just as I was going to start SDA on the source provided by IBM, I stopped in my tracks and copied the source into one of my libraries, from where I would make the changes. If something went wrong, I thought, I could always re-use the original source to reconstruct the standard Sign-On display.
Fine. I started SDA, and just as I was about to finish, I remembered to resequence the fields by image position, just as it had become a habit with me to do in my S/36 days. So with the panel image on my terminal, I pressed F4 to display all fields, then F6 to sort. A nice information message told me that they had been sorted. I recompiled the display file and there was no problem.
Gotcha! The problem came when I restarted QINTER. The Sign-On display would not work. What could have possibly gone wrong? I compared my source with the original IBM source (good thing I still had it in QGPL), and saw that there is a hidden field called UBUFFER, 128 characters long, which had shifted from the bottom of the DDS to the top, after sorting fields by image position. Obviously enough (realized in hindsight, naturally), hidden fields must have position 0 in row 0 or something to that effect, so they had to shift to the top of the DDS.
The solution to the problem, then, was to start SEU (not SDA) and move the UBUFFER field again to the bottom, recompile the display file, and restart QINTER. Everything worked fine after that!
- Ernie Malaga