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.
Adopted Authority
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
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online