|
An important thing is to come up with a SYSTEM for your offices. We designate an office as belonging to a PERSON (use their initials) or a DEPARTMENT (use a few letters that identifies them). Here are some examples. BUYA0002 is session # 2 on the PC in the Buying Department's Office-A. SHIPE0001 is session # 1 on the PC in the Shipping Office in Building-E. JOE0003 is session # 3 on the PC in Joe's office. JIT1 is session # 1 on the twinax work station in the Production Office. (JIT means Just in Time). MFG1 is session # 1 on the twinax work station in the Plant Manager Office. CBOS4 is OS4 main console (C for stuff in computer room - BOS because this console is the boss of the whole operation). When we get new connections ... either use the user name initials or office designation ... we can review WRKCFGSTS *DEV to see what has already been used, if we end up with two of same office or two of similar name. > 2. Most emulators have the ability to specify device names. If you don't > you get a QPADEV*. Check out the session config for each one. Normally, if > you try to use the same device name from different PCs, there will be a > conflict. Some clients have a way to auto-increment the name somehow. Another important thing is to understand how AS/400 iSeries manages the rules that apply to the stuff that you want different for different offices. Something extremely critical to us is where reports are to print & which reports to be on automatic hold vs. automatically released. Thus when some report ends up in the wrong place we do not go insane trying to figure out something & end up with different rules for different reports. If we use 100% defaults, which we do not, then the bottom line rule is DSPSYSVAL QPRTDEV which in our case is PRT02 the system printer. At this point all it is doing is designating the printer, not rules about alignment, what on hold etc. When we see something saying PRTDEV(*SYSVAL) that means check the system values & use whatever is there. System Values are about 120 rules that govern everything that runs on AS/400. You can WRKSYSVAL then select a category & find interesting one & 5-view it current setting & choices & F1 help explanation. If your company 400 has been around a lot longer than you have been there, you might want to WRKSYSVAL F4 & get a *PRINT ... ours is only 3 pages ... those values changed from IBM defaults are flagged. Device rules OUTQ(*DEV) can override System Values. My interest at this level is not to use this feature & just focus on IS THE DEVICE WORKING RIGHT & avoid any fancy stuff that could get messed up if the device not working, disconnected, reconnected, auto config, rename sucker, and defaults lost anything we did out of the ordinary. When we see something saying OUTQ(*DEV) that means to get the information from the Device rules. Work station rules (*WRKSTN) can override Device rules. This is what we use primarily, due to our application software. User can take a menu option & specify what printer & JOBQ they want the stuff from that work station to go to, do they want it on hold, and a level of priority to use. Then when the application software runs, it grabs the answers from this work area supplied in a data structure for each unique work station address like BUYA0001 MIKE0003 etc. User profile (*USRPRF) sign-on rules can override Work station rules. This way if you have traveling users who may be at different desks & different offices on different days, you can have reports go where THEY want them, instead of to the office printer for the work stations in that work group. Job Description (*JOBD) rules can override User profile rules. We have everyone pretty much on same one due to our Application software supplying library list & like that, but I do have a few people setup for a modified JOBD, that is a copy of the main one with a few additions. Problem is with Query/400 which runs from a different *JOBD which apparently defaults to print ... some day I need to figure out how to over-ride that because we got people doing WRKQRY from command line, then bitching because their report printed & they had wanted to look at it on screen. CL programs can override Job Description. When someone runs a program from a menu it can have OVRPRTF statement, saying I don't care what the standard rules are, we do not want this report to print. Or for example, if anyone changes a customer order, does not matter in what department they do it, the audit trail prints in the customer service department. And there's more ... I had a case today where SFC730 report printing & they not want it ... I check CL for SFC730 & it says HOLD(*YES) on the OVRPRTF ... well come to find out SFC540 RPG program calls SFC730 RPG program & every time they change one shop order it kicks out one page of SFC730 audit trail, so now I have a HOLD(*YES) for the SFC730 report right before SFC540 CL calls the outer RPG & it now works the way they want it. If you GO CMDREF there is a way to get from top down for some program what objects it calls. Well I did that for *ALL programs to an *OUTFILE then RUNQRY against the results looking for what programs call the SFC730 PRTF. Hoping I have been helpful. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
