View Full Version : Anyone Using Ops Nav?
06-23-2001, 06:10 AM
Recently an IBMer chimed that IBM has made many enhancements to OpsNav....... Now if only they can get someone to actually use it. Dave
06-23-2001, 08:39 AM
Not if they can help it. Probably because green screens fail about once every 3 - 5 years and PCs running Windows and CA fail about what once a day. Which one would you want to do critical system level work on if you had a choice?
06-23-2001, 11:39 AM
Thanks to both Dave and you for the insight. Please bear with my novice background, but what I don't understand is if you have more than one PC with a connection to CA and Ops Nav, so what if one fails? Couldn't another PC connection be used? It's understandable that the reliability of running CA through a single PC is not at all desirable, but with multiple connections couldn't you still access Ops Nav and still manage the system? PS: I am not one of the young and restless that grew up on GUI s. I'm starting my next life at 54 (retired military) as an entry-level programmer and console operator.
06-24-2001, 02:47 AM
I agree. Most people who have been working with the 400 for the past gazillion years are so familiar with operations commands that (for most) prompt screens are no longer necessary. Entering the command, and getting the appropriate info takes less than seconds. Has anybody timed Ops Nav, even on a high powered PC? If you want to get anything done quickly, and move on to the next task, this is most definetly not the way to go. I had to use it for NETSERVER set up. It was not intuitive, and I had to re-do the task two or three times. I don't want to use it for creating tables, as making changes or adding fields is a bear. I looked into using it for DOMINO, but felt that 5250 land was easier, and far more complete, as I can not see the DOMINO console through Ops Nav. I do not use OpsNav at all for two of my clients. For the third the only daily reason to use it is when a user comes to me with a problem, and I do not want to leave my existing screen, and/or open another 5250 session. OpsNav is fun to explore, to see what you can do, but working with the product on a regular basis, is not very efficient compared to normal operations. OTOH, I can see where OpsNav would be useful in a shop where there was no interactive processing. OTOOH, there are zero shops of this nature in my user group. Dave
06-25-2001, 01:56 AM
Speaking from the vast experience of someone who has never seen Ops Nav... From what I understand it is a tool that allows you to perform admin type tasks by drag and drop in a GUI environment rather than dirtying your hands with CL. However, smart administrators nearly always perform these tasks in custom written programs rather than simply keying commands at the workstation. This ensures that the tasks are carried out in a standard repeatable way. Why would anyone want to move from precision control to drag and drop anarchy? Dave...
06-25-2001, 04:13 PM
"Is anyone else out there using Ops Nav to create PF and LF? Is there a text (extant or planned), incorporating V4R5 and above, that provides solid details on using Ops Nav?" ------------------------------------------------------ I, too, would be interested in hearing from anyone able to answer Bob's original questions. However, I would also ask if anyone is using SQL to create new physical files and their corresponding external file descriptions. If so, where can one find the best documentation on doing this? Hello! Anyone out there doing either of these things?
06-25-2001, 06:47 PM
I guess I am one of the few who finds the Run Query interface far more productive than the interactive green screen strsql version. I do not use the wizards for creating files because I find it faster to key in the statement directly, but that is only because I am fairly familiar with the DB2 create statements. On other systems like oracle, I use wizards quite a bit. I started doing this when I saw that IBM was putting their effort into the SQL interface. I do eventually save my sql scripts to an iSeries source file for the source control benefits. David Morris
06-26-2001, 03:55 AM
As a 20-year veteran of the IBM midrange, I never use Operations Navigator for my own administrative tasks unless it is the only way to accomplish something. When training new administrators or demonstrating functions to managers, I always use Operations Navigator because these new folks are familiar with the interface from working with other systems. From a marketing perspective, the iSeries can be doomed by a rigid belief that the green screen is the only way to run it. While I agree that the green screen offers precision, clarity, and speed for those of us who have memorized hundreds of cryptic commands over time, I would also put forward the idea that one of the things that the technical old guard can do to assure the continued viability of our platform is to visably use Operations Navigator. Technical excellence and a dollar might buy you a cup of coffee, but people who buy computers do so for a wide variety of reasons. One factor which is frequently considered is the perceived staffing and training costs. If your system requires a green-screen guru to run, then these people might well decide to buy something that appears to be easier to run like Windows 2000. Most of us in this forum know that if technical excellence were the only purchasing criteria, then we would be up to our armpits in AS/400's. Many other executives don't want to be caught running old technology, this includes anything that runs on a text-based screen. All of the points raised in the preceeding posts are valid, but I would urge the veterans to use the product when appropriate. Ops Nav has gotten better and more functional with each release. We have recently seen some senior members of our community urge us to find ways to 'market' the iSeries within our own organizations. One of the things we can do to counter perceptions of our platform is to embrace some of the sexier interfaces, even if we don't think they are as stable or productive as a green screen. Then we need to get IBM to do something about the price. IMHO, Andy
06-26-2001, 06:12 AM
Andy, I couldn't agree with you more!! If we want the iSeries to be around for a long, long time we MUST be adaptable to the new tools and techniques provided. If we persist in living in the past, the box will eventually be a box of the past and will die. Having said that, there are a lot of things that are "easier" to do in green screen, because we solved those problems long ago and are familiar with those tools, CL etc. There are a lot of things you can only do in OPS NAV and those features should be exploited. I love the drag and drop of USRPRF's from one machine to the other. Our 400's are used for development and just about everyone has profiles on multiple machines. Their authorities are different but setting up their profiles is a snap. You may have a CL that does this already, fine. Use the tool that works for you but please be open to the idea that this box MUST move forward. The tool that you choose may not be the one your subordinate or peer uses.
06-26-2001, 07:20 AM
I'm currently working with setting up some new AS/400s. The biggest advantage is in some of the Wizards. Ops Nav does have some good wizards that help in setup. Most of the things you do in Nav you had better know the green screen commands too or when something screws up you won't have a way to get to root of the problem. Some of the things I like about the Ops Nav I do like using Ops Nav for adding new users and groups. It is quick for working with authority issues. Scheduling Backups and IPL. And some IFS Documents. But to be honest, you can do any of these tasks just as easy from the green screen. Here is the problem for Dave and some of the other older profits. IBM is forcing some config to be done through the Ops Nav and from what I can see you can expect more of it come. Example: Iseries 400 comes with an Internal PPP modem for for the ECS line. However, you can't configure that modem unless you have Ops Nav up and running. Better be ready to change boys (lol) and girls too! I personally enjoy the green screen but I'm learning to deal with the Ops Nav too.
06-26-2001, 10:01 AM
The thing that really yanks my chain, is that OpsNav is part of the default CA install. In one shop, a manager gave OpsNav to nearly everyone because, all his experience was centered around taking the defaults. In the entire shop, I'm the only person to use OpsNav at all. When I get a question, it's usually along the lines of "What's that icon for?". I try to deinstall that option whenever possible for most users. Dave
06-26-2001, 10:48 AM
One of the problems with OPS NAV is that it doesn't follow "normal" AS/400 security. Sometimes OPS NAV issues commands(security works fine) and sometimes it uses API's(bypassing security). IBM couldn't/wouldn't tell us which use which. For instance, a USRPRF with Limit Capabilities *YES can still get a command line in OPS NAV. Everyone should let IBM know that this is unacceptable and needs to be fixed ASAP. Anyone with a CA CD could install OPS NAV. What would be nice is a centralized install for CA so you could give users only the features they need. (As well as plugging the security holes)
06-26-2001, 02:42 PM
<DIV><FONT face=Arial size=2>Chris, </FONT></DIV> <DIV></DIV> <DIV><FONT face=Arial size=2>Isn't that taken care of via System Policies?</FONT></DIV> <DIV></DIV> <DIV><FONT face=Arial size=2>Bill</FONT></DIV> <BLOCKQUOTE style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> For instance, a USRPRF with Limit Capabilities *YES can still get a command line in OPS NAV.</P></BLOCKQUOTE>
07-22-2001, 11:28 AM
Our small shop just upgraded to V4R5 and we have been using Ops Nav to schedule night and weekend jobs. Although the instructions are somewhat cryptic, the GUI interface to set up the scheduled tasks is very good. However, detailed information on HOW to use the various features contained in this latest enhancement seem to be very sparse or non-existent. The Ops Nav help contents typically describe WHAT it can do for you but very little in the HOW to do it department. Case in point: I created a table (physical file) using Ops Nav, and it was seemingly very easy to do. However, when I wanted to go back and change one of the field attributes in that table I couldn't find any info on how to do it. When you look at the data base help topic, it lists a number of instructions for creating tables, deleting tables, sharing, etc. Towards the bottom of the list is "editing tables". This topic is not hyperlinked as the others are, therefore you can't "go there". I also think it refers to editing data in the table, not modifying any fields nor their respective attributes. When I went to the IBM site searching for info on this, the only pertinent topics I saw were pages that described the features and version enhancements of Ops Nav. I down loaded the Red book for Client Access today for further info, but it only addresses how to install and connect Ops Nav to the AS/400 and systems management. Is anyone else out there using Ops Nav to create PF and LF? Is there a text (extant or planned), incorporating V4R5 and above, that provides solid details on using Ops Nav?
07-22-2001, 11:28 AM
Bob - Take a look at this. I've copied some information over here from MC Forums Archive AS/400 Applications December Article by Ted Holt: The Death of OPNQRYF Bret Myrick - 12:01pm Dec 12, 2000 PST Ted, Having just read your most excellent article, I must confess that in my opinion OPNQRYF died years ago. That was when I installed ASC's SEQUEL, SQL package. It allowed me to embed SQL statements inside standard CL without having to use Query Management or embedded (shudder) SQL from RPG. This ability alone was cause for me to purchase this product twice more in the last 10 years. One for a client and one for another company I was with. I certainly wish IBM would get on the bandwagon about interoperability and standards. -bret [ Bookmark ] -------------------------------------------------------------------------------- [ First Msg ] [ Previous Msg ] [ All Msg ] [ Outline ] (11 previous messages) -------------------------------------------------------------------------------- Ted Holt - 11:48am DEC 14, 2000 pst (126.96.36.199.1) [ Bookmark ] December Article by Ted Holt: The Death of OPNQRYF Ralph said: They need to leave DB2/400, its embedded relationship with OS/400, and record level access alone. It's paid for, just sell it. All the old stuff will still be there, Ralph. You'll still be able to create physical & logical files with DDS, run OPNQRYF, write RPG programs with F specs, etc. IBM is saying they're going to continue to enhance DB2/400 to bring it up to par with DB2 UDB, but the native interface won't include these enhancements. What the enhancements are, I don't know. Maybe I'll email the guy I know in database development & see what he can tell me. But I expect we'll see support for other types of joins & update thru a join. Of course, if you don't need the new stuff, you don't have to use it. I know people who still write and maintain S/36 code. They've never even made the switch to RPG III, externally described disk files, and CL. -------------------------------------------------------------------------------- Ralph Daugherty - 11:57am DEC 14, 2000 pst (188.8.131.52.1.1) [ Bookmark ] December Article by Ted Holt: The Death of OPNQRYF Thanks for the info, Ted. It sounded like they were abandoning AS/400 technologies because it was too expensive to maintain parallel products. I'm glad to hear that's not the case. Cheers, Ralph email@example.com -------------------------------------------------------------------------------- Frank Whittemore - 01:57pm DEC 16, 2000 pst (184.108.40.206) [ Bookmark ] [ Delete Message ] The Death of DDS for external file descriptions Using SQL for your database objects is in synch with IBM's long-term plans for DB2 UDB for AS/400. SQL is the strategic interface for DB2 UDB for AS/400, and therefore SQL has higher priority in Rochester than DDS. DDS usage won't be eliminated completely -- you'll still need DDS for creating display and printer files because no SQL equivalent exists for those file types. The most logical way to begin migrating to SQL file definition is to create your SQL database script in a source file member and then point the RUNSQLSTM (Run SQL Statement) CL command at that file member. RUNSQLSTM will execute the SQL and create your database objects. In the future, Operations Navigator will give you a graphical interface for creating and running SQL database scripts. -------------------------------------------------------- The above text has been copied from the following IBM site. For more information click here http://www.iseries.ibm.com/developer/bi/sql.html
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.