[IMAGE]
[IMAGE][IMAGE]
Ken Graap
[IMAGE]
[IMAGE]
Ken Graap, iSeries i5/OS expert, has been answering Search400.com's member questions for over five years. Ken has seen many of the same issues and concerns asked over and over. Therefore, we've compiled the top 10 questions asked about iSeries i5/OS for you. Do you have a question that's not listed here? Ask Ken your i5/OS questions.
TABLE OF CONTENTS
[IMAGE] 1. Creating a command shortcut for WRKOUTQ PRT03
[IMAGE] 2. Moving a spool files from one system to another
[IMAGE] 3. Editing a word document stored in an IFS shared directory
[IMAGE] 4. Setting up Remote Journaling between two i5 servers
[IMAGE] 5. Control the creation of job logs on your system
[IMAGE] 6. Distribute copies of spool files to several different printers
[IMAGE] 7. Set up you i5 system to forward email to a corporate email system
[IMAGE] 8. Secure production data from PUBLIC access
[IMAGE] 9. Run as another user without having to sign on as that user
[IMAGE] 10. Set up secure access to a command line from an interactive job
[IMAGE]1. Creating a ...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
command shortcut for WRKOUTQ PRT03[IMAGE]Return to Table of Contents
I need to create a command shortcut for WRKOUTQ PRT03. How do you recommend I do this?
I would suggest that you create a simple command using the QCMDEXC API and then passing it a "constant" value, like this:
Have any other "shortcuts" you would like to create? Consider using this technique instead of creating duplicate system commands.
[IMAGE]2. Moving a spool files from one system to another[IMAGE]Return to Table of Contents
I need to move spool files from one system (V4R4) to another (V5R3). Is there an easy way to do this?
Let's assume that your two systems are connected via TCP/IP. Then all you would have to do is create a remote *OUTQ on the V4R4 system pointing to an *OUTQ on the V5R3 system. Any spool file placed on this remote *OUTQ would then be sent to the V5R3 system.
Here is and example for creating a remote *OUTQ:
CRTOUTQ OUTQ(mylib/remoteoutq) -- The *OUTQ on the V4R4 system.
RMTSYS(v5r3sys) -- The DNS name for the V5R3 system.
RMTPRTQ('mylib/v5r3outq') -- The *OUTQ on the V5R3 system.
AUOSTRWTR(1)
CNNTYPE(*IP)
DESTTYPE(*OS400)
Note: If the writer associated with this remote *OUTQ needs to be restarted for any reason, you would have to use the STRRMTWTR command instead of the STRPRTWTR command.
[IMAGE]3. Editing a word document stored in an IFS shared directory [IMAGE]Return to Table of Contents
When I edit a Word document stored in an IFS shared directory, the Word program's temporary files aren't being deleted after I save the document. Why can't Word clean up after itself when using the IFS?
What I believe is happening is that the authority to the IFS directory you are creating your documents in is insufficient.
When a user creates a new file in an IFS directory they become the owner of the file and therefore have all data rights, but the OBJECT authority assigned to the file is based on the authority of the directory it is placed in. Here are the rules:
The owner for the new object has the same object authorities that the owner of the parent directory has to the parent directory.
The primary group for the new object has the same object authorities that the primary group of the parent directory has to the parent directory.
*PUBLIC has the same object authorities to the new object that it has to the parent directory.
In your word processing example, the word processing program creates a temporary file when a file is created or opened for edit. When the user finally saves the document and exits, the PC program attempts to rename the most current temporary file to the original file name. If the user's objects didn't get sufficient private authority from the parent directory (which I suspect they aren't) then this operation can't be completed.
So, check to see whom the OWNER of the parent directory is and what authority they have to it because this will be the authority assigned to any new object created in that directory.
If the OWNER of the directory is different than the user creating the object in the directory (which is probably the case) then the *PUBLIC authority setting comes into play.
The simplest fix to your problem may be to assign *PUBLIC authority, such as:
Oh, by the way, here is IBM's explanation of "mgt object authority":
[IMAGE]4. Setting up Remote Journaling between two i5 servers[IMAGE]Return to Table of Contents
How can I set up Remote Journaling between two i5 servers?
This is easier that you might think.
First of all, you will need to establish a TCP/IP connection between the two machines. This could just be an Internet connection. My guess is that you have already done this.
To enable Remote Journaling you would do the following:
1. Define Journaling on the SOURCE system.
For Example:
a. Create a message queue to receive journal messages:
CRTMSGQ MSGQ(QGPL/LAWJRN) TEXT('Lawson
journal messages')
b. Create a journal receiver in the proper journal receiver library:
CRTJRNRCV JRNRCV(JRNRCVLAW/LAW2JR0001) THRESHOLD(1000000)
c. Create a journal referencing the receiver just created:
CRTJRN JRN(LAWP1FILES/LAWP1JRN)
JRNRCV(JRNRCVLAW/LAW2JR0001)+
MSGQ(QGPL/LAWJRN) MNGRCV(*SYSTEM) DLTRCV(*NO) +
RCVSIZOPT(*RMVINTENT *MAXOPT2)
2. Create a Relational Database entry to identify the DB on the system you wish to journal to.
For Example:
ADDRDBDIRE RDB(REMOTESYS)
RMTLOCNAME('10.10.10.110' *IP)
TEXT('My Remote system')
3. Create a Remote Journal.
For Example:
ADDRMTJRN RDB(REMOTESYS) SRCJRN(LAWP1FILES/LAWP1JRN) TGTJRN(RMTJRN/LAWP1JRN)
RMTRCVLIB(RMTJRN) TEXT('Remote journal
for LAWP1FILES')
4. Decide what objects you want to journal and start journaling them.
5. Manage your remote journaling environment.
[IMAGE]5. Control the creation of job logs on your system[IMAGE]Return to Table of Contents
How can I control the creation of job logs on my system?
There are several components to how job logs are created on a the system.
The message logging parameters determine what kind of information will be collected:
I won't go into all the specifics related to these values, but if the message logging 'TEXT' parameter is set to *NOLIST a job log will only be created if the job ends abnormally. If the job completes normally, no job log will be created.
This is the same whether the job is an interactive or batch job.
If any value other than *NOLIST is specified for the message logging 'TEXT' parameter in a batch job, a job log will always be produced, whether the job ends normally or abnormally.
This works differently for interactive jobs though. In order to conserve disk space the SIGNOFF command has been defined as:
So, by default, when an interactive job is ended normally, no joblog will be produced.
However, if the interactive job ends abnormally a joblog and most likely a program dump, will be produced.
If you want to force the creation of a job log from an interactive job you can do it in one of two ways.
1. When you sign off enter SIGNOFF LOG(*LIST).
2. Prior to signing off enter DSPJOBLOG OUTPUT(*PRINT).
When one of these options is used a job log is created.
On V5R4 of OS400 the job log creation process has been enhanced. To review the changes, following this link.
[IMAGE]6. Distribute copies of spool files to several different printers[IMAGE]Return to Table of Contents
I need to distribute copies of spool files to several different printers. Is there an easy way to do this without having to purchase additional software for my system?
Yes, I think there is a "simple" process for distributing copies of spool files to different printers using just basic OS/400 commands and definitions.
With just a few simple user profiles, distribution entries and
the SNDNETSPLF command you can create a spool file distribution system.
You'll find the pieces in a past tip of mine"Distribute spool files to printers easily."
[IMAGE]7. Set up you i5 system to forward email to a corporate email system[IMAGE]Return to Table of Contents
How would I set up my i5 system to forward email to my corporate email system?
To enable email forwarding from your i5 server requires that you do a couple of things.
First, you need to change the System directory Attributes via the CHGSYSDIRA command:
CHGSYSDIRA USRDFNFLD((FORWARDING *NONE *ADD *ADDRESS 256)
(FWDSRVLVL *NONE *ADD *MSFSRVLVL 1))
This sets up the User defined fields like this:
Change System Dir Attributes (CHGSYSDIRA)
Type choices, press Enter.
Next you need to define where to forward email to for each user's directory entry. In this example, I will define that any email delivered to i5 user KEG to be forwarded to their internet email address: keg@nwnatural.com
CHGDIRE USRID(KEG S02) USRDFNFLD((FORWARDING *NONE KEG@NWNATURAL.COM))
MSFSRVLVL(FWDSRVLVL *NONE) PREFADR(FORWARDING *NONE MIME)
This change can be verified from the DSPDIRE USRID(KEG S02) screen via the F20 key:
That's all there is to it.
[IMAGE]8. Secure production data from PUBLIC access[IMAGE]Return to Table of Contents
How can I secure production data from PUBLIC access, on a system used for both production and development work?
One solution would be to set up two partitions on your system, production and development. However, sometimes this isn't possible for a number of reasons.
Another solution is to utilize OS/400 security to create separate application environments within a single partition.
This can be done using Adopted Authority and Application Access programs.
Environment:
1. Access to the production environment is denied to the public by default (*PUBLIC *EXCLUDE)
2. The change management profile (CHANGEMGT) will have *ALL access to production objects… Source, Data and Programs.
3. Development users will be able to READ production source.
4. All users can EXECUTE production programs to allow for testing with development data.
5. CHANGE access to production data, will be granted to authorized production users through a Production Application Access program set to adopt authority.
Implementation:
Production source files will be owned by user profile PRODSRC
The libraries and objects within the source libraries, will have *PUBLIC *AUTL authority defined and be secured by an authority list named PRDSRC
Authority granted through authority list PRDSRC will be:
This prevents general users from accessing production source files, but allows development users READ access. Of course the CHANGEMGT profile has all authority so it can be used to maintain the application.
Production application data will be owned by user profile PRODDATA
The libraries and objects within the libraries, will have *PUBLIC *AUTL authority defined and be secured by authority list PRDDATA
Authority granted through authority list PRDDATA will be:
PRODAAP *CHANGE *PUBLIC *EXCLUDE CHANGEMGT *ALL
This insures that production data is excluded from all but PRODAAP. Production uses will adopt this authority to access the data.
Production application programs will be owned by user profile PRODAPP
The libraries and objects within the application program libraries, will have *PUBLIC *AUTL authority defined and be secured by authority list PRDAPP
Authority granted through authority list PRDAPP will be:
This provides access to the application code for all users. This is OK because they can only use these programs to access data they own (test data) unless they adopt authority from a Production Application Access program, and only production users have access to Production Application Access programs. CHANGEMGT has all authority so it can be used to maintain the application.
All production user profiles will have an initial program of PRDAAP defined.
Program PRDAAP will be owned by user profile PRODAPP and defined to adopt the program owner's authority - CHGPGM PGM(PRDAAP) USRPRF(*OWNER).
Authority to program PRDAAP will be:
This is the KEY to the whole configuration. Only members of the PRODUSER group will be able to execute this Application Access program and adopt the authority necessary to access production data! Development and test users would have Application Access Programs that don't adopt authority and therefore they could not access production data even if they could modify their library lists.
Production Application Access programs will need to be created for each type of access, Interactive, Batch, ODBC etc… These programs will need to be set to adopt the authority for user PRODAAP too.
When a Production Application Access program is used, authority to production data is allowed via program adoption.
The following graphic illustrates this whole process.
[IMAGE]
[IMAGE]9. Run as another user without having to sign on as that user[IMAGE]Return to Table of Contents
How can I run as another user without having to sign on as that user?
OS/400 does have API's that allow you to swap to another user profile within your current job. These programs are usually used to swap profiles within a server program, but you can use them to swap within your programs, too.
To maintain secure access to user profiles there are a few requirements that need to be met before you can perform a user swap.
First of all, the source and target user profiles will need to have *USE authority to the swapping API programs, QWTSETP & QSYGETPH. Both programs will need to have *USE access to each other before swapping can occur, too.
Once these requirements are satisfied, the following program could be used to swap to another program without having to supply a password:
Note: This program code is enhanced to monitor for errors and notify the System Administrator when they occur. These enhancements are optional to the swapping process, but it isn't a bad idea to monitor the use of a program like this.
[IMAGE]10. Set up secure access to a command line from an interactive job[IMAGE]Return to Table of Contents
How can I set up secure access to a command line from an interactive job?
One way to do this is to modify how the System Request menu works.
By default the System Request 90 option will execute the SIGNOFF command.
This option is defined by the contents of Message Description CPX2313, which can be found in message file QSYS/QCPFMSG:
A simple command can be written that will check an authority list and call the command line API (QUSRCMDLN) if a user is authorized or just sign off the user if they aren't authorized to get a command line.
To implement this process do the following:
First define an authority list named SYSRQ90. Add the names of any individual user or group profiles you would like to give command line access via System Request 90, using the following commands:
For individual users: ADDAUTLE AUTL(SYSRQ90) USER(xxx) AUT(*USE)
For group profiles: ADDAUTLE AUTL(SYSRQ90) USER(xxx)
AUT(*USE *AUTLMGT)
Next modify the CPX2313 message replacing SIGNOFF with SYSRQ90:
Do WRKMSGD CPX2313 and then use Option 2 to get the following prompt of the CHGMSGD command:
Make sure you don't change the spacing between the commands in this list. They have to be entered exactly as shown or System Request will not function correctly!
Create the following program and command:
CRTCLPGM PGM(QGPL/SYSRQ90)
CRTCMD CMD(QGPL/SYSRQ90) PGM(QGPL/SYSRQ90)
Here is the command source:
CMD PROMPT('System Request 90')
That's all there is to it. The next time a user does a SYSTEM REQUEST 90 option they will either be signed off, or they will get a command line, depending on if they are on the SYSRQ90 Authority List or not.
