|
1) The message queues are very easy to setup and deal with. Just specify the queue name you want and a library where you want to keep them. I created a lib called IXS and keep all my IXS message queues there. I have them set so they record all three types of messages, security, system, and application. I haven't gone to them much because they basically record the same info as the Windows Event Viewer. Looking at mine, they are around 16mb and wrap when full. If you had a need to monitor for certain Windows events from the iSeries they would be very useful. 2) I'm letting the LICPGM install be covered by our monthly Option 21 backup. If you have a need for other saves of the actual server descriptions and objects it's very straightforward. Here's a basic manual procedure I put together (could easily be incorporated into whatever strategy is desired): SAVE If needed, the IXSs can also be saved individually by using the following procedure to get all the components (using IXSSRV03 as an example): This procedure will make use of sequence numbers on a single freshly initialized tape, so specify an incremented sequence number with each command and use ENDOPT(*LEAVE) SAVCFG DEV(TAP01) Saves all configuration data on the system. This covers the Network Server Description and the line/controller/device comprising the PTP Virtual Ethernet Interface for the IXS. SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV031') Saves the 'system' storage space (drive c: of the IXS) SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV032') Saves the 'install' storage space (drive d: of the IXS) SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV033') Saves the 'application' storage space (drive f: of the IXS) Repeat the step above for any additional NWS storage spaces used by the server. If any other drives exist, they need to be saved. SAVOBJ OBJ(IXSSRV03) LIB(IXS) DEV(TAP01) OBJTYPE(*MSGQ) This saves the message queue that receives messages from the Windows server. RESTORE IXSs (or individual components of them) can be restored individually (from an individual save, or an Option 21 save) by using the following procedure (using IXSSRV03 as an example): RSTCFG OBJ(IXSSRV03) DEV(TAP01) Restores the Network Server Description (be sure to specify IXSSRV or you will restore ALL config data!) RSTCFG OBJ(IXSSRV03*) DEV(TAP01) Restores the line/controller/device comprising the PTP Virtual Ethernet Interface for the IXS RST DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV031') Restores the 'system' storage space (drive c: of the IXS) RST DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV032') Restores the 'install' storage space (drive d: of the IXS) RST DEV('/QSYS.LIB/TAP01.DEVD') OBJ('/QFPNWSSTG/IXSSRV033') Restores the 'application' storage space (drive f: of the IXS) RSTOBJ OBJ(IXSSRV03) LIB(IXS) DEV(TAP01) OBJTYPE(*MSGQ) Restores the message queue that receives messages from the Windows serve You get the picture. For save/restore/config/deletes on IXSs I just try to keep in mind the pieces (hardware resource,NWSD, IP interface, lin/ctl/dev comm objects, storage spaces, message queues), I LOVE the save/restore abilities of these servers... we have used it multiple times for many purposes. For example, right now we're testing some web filtering products... I config'ed a server, got it all patched and basically configured for what we want, and saved it to a tape. We loaded one web filter product, tested for a week, blew only the C: and F: NWSSTG spaces away when finished, and then restored the C: and F: storage spaces to be back to our fresh config (5-10 minutes of work!). Alternatively, we could have saved the results of our testing to another tape and easily switched between our various eval products almost at will. IBM did a great job on this, IMHO. "Jeff Crosby" <jlcrosby@dilgard foods.com> To Sent by: "'Midrange Systems Technical midrange-l-bounce Discussion'" s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 09/22/2005 09:56 Subject AM IXS/IXA practices Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> I was reviewing stuff in the "Microsoft Windows Server 2003 Integration With iSeries" redbook and stumbled across a few new things. I was wondering about: 1) The network server description has a MSGQ parm. It can be *NONE, *JOBLOG, or a message queue name. Mine is set to *JOBLOG. I looked at the joblog and there is a lot of good info there. Seems reasonable to have a message queue for this purpose. What are the rest of you doing? 2) Disaster Recovery backup. What needs backed up is listed. One of the things is library QNTAP. Redbook says this can be backed up via SAVLICPGM. I ass-u-me that if BRMS is regularly saving all the objects in that library that I'm covered and there is nothing magical about SAVLICPGM. 3) How many thin clients do you think a single IXS card would support? I've got 5 on now and have 5 older PCs that could use replacing Real Soon Now. 4) The clustering stuff sounds interesting. Can multiple IXS cards share the same storage space(s)? And be made to share the load of thin clients? Thanks. -- Jeff Crosby Dilgard Frozen Foods, Inc. P.O. Box 13369 Ft. Wayne, IN 46868-3369 260-422-7531 The opinions expressed are my own and not necessarily the opinion of my company. Unless I say so. -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _____________________________________________________________________________ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _____________________________________________________________________________ ForwardSourceID:NT0002CB12 _____________________________________________________________________________ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _____________________________________________________________________________
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.