SNA on V6R1

[soup_dog]

Not sure where to post this, so I am posting it here. We are currently running on V5R3 and are getting ready to buy a new box and upgrade to V6R1. I have a number of users that are using an old SNA client to run macro's. Does anyone know if those same clients should still work under V6R1? (In other words, can V6R1 handle SNA connections?)

Sorry, if that is not very clear but to be honest, I don't know very much about how they work.

Thanks in advance,

Soup.

[MichaelCatalani]

Re: SNA on V6R1

SNA is still an option for things like DDM Files under 6.1. If you can print a config of a client, I'll see if I can somewhat duplicate it on my machine.

[soup_dog]

Re: SNA on V6R1

I'll see what I can find. I'm not very familiar with the product they are using. I think it's pretty old.

[MichaelCatalani]

Re: SNA on V6R1

I'll see what I can find. I'm not very familiar with the product they are using. I think it's pretty old.

If it's a true "product", the bad news is that the software may not migrate to the new box because there's a re-encapsulation process that has to be performed when going from V5R3 to V6.1. (Just like what happened when we went to the Risc processors in V3R1. ) There's a migration tool program that you can run that will check your system for programs that have observabilty removed. It will then generate a list of programs that can not be automatically converted by the system, in which case you will have to get a software release from the vendor which is already compiled at 6.1. If this is a dated product, there may not be a newer release for it, and it may not convert up to 6.1.

[gcraill]

Re: SNA on V6R1

We're in exactly the same scenario Soup - we need to share on this one

To check connectivity we generally use aping, and as a fucntion we use SNA for SAVRSTOBJ.
I haven't set up the SNA controllers here though, so no idea how that is done.

[soup_dog]

Re: SNA on V6R1

Ok, sorry about the delay responding. I don't know too much about this stuff so bear with me. Apparently, there is a small group of people here who are not using the standard client access emulator. they are using an SNA emulator called WINAPPC which gives them terminal functions on the AS400. Now the part I don't understand. THe network guys want to get rid of this SNA client front end because they are required to run some antiquated SNA server that they don't know how to support. THe users dont want to get rid of it because it gives them much "nicer" macro-functions that client access does not. (In addition to a few other features that are not that important.)

So my questions are these: Why the heck does the network guys need to run some kind of SNA server to support this front end? Isn't this just a communication between the user's pc and the AS400? Where did a network server come into the picture?

Since this is just a "front end" terminal emulator, shouldn't it still work for V6R1? Wont the programs the emulator uses on the AS400 automatically be converted when we upgrade the operating system?

Thanks a bunch!!!

[tomholden]

Re: SNA on V6R1

i have no clue what "macro" functions they might have that can't be duplicated in CA. (sounds like they just don't want to (or have forgotten how to do their job manually))

many many many moons ago (like MS windows 3.11) NS router used SNA but it has supported TCP/IP for years now. why they would still need SNA at this point boggles the mind. even the sucky BosaNova emulator with the emulator cards uses TCP/IP. sounds like they need to research the emulator to me. the other sucky emulator i've seen is the old ES/TCP thing...as the name implies it uses TCP. i have no clue what they are looking at nor why they think an SNA server is necessary. what is the name & version of the emulator? the only WINAPPC emulator i could find supports TCP http://www.fhl.com/winappc.htm

[soup_dog]

Re: SNA on V6R1

Here is an example... There are a number of functions that are users need to do that are very "ad hoc". We have thousands upon thousands of different kinds of parts. Every now and then someone may say, we need to change this group of parts to do this. Which would involve going into the part maintenance screen, making the appropriate change and pressing ENTER. Repeat a couple hundred times. Now, with the WINAPPC macro, the keystrokes are layed out to the right, so they can be pasted into an EXCEL spreadsheet easily. Then all the user needs to do is paste the part number into the appropriate column, save the new macro with the hundreds of lines, and then press ENTER.

Unfortunately, Client Access builds the macro going DOWN. Which means a lot more work when trying to repeat the same keystrokes hundreds of times. SO basically, the client access function does not save them any work.

Yes, we could write a program on the AS400 to do this, but that could take days. This takes minutes.

[tomholden]

Re: SNA on V6R1

seems that the time saved by not having to cut & paste would be more beneficial and i'd simply write the program. it would save them lots of time going forward...but that's just me. someone had to spent a good amount of time putting together the Excel spreadsheet (which imo isn't as reliable and error prone than a program)

[gcraill]

Re: SNA on V6R1

Client side scripting that updates the database is a bit risky IMHO, sooner or later someone will mess with it and then it all get's bust because someone expected the macro to do "X" but today it all went and did "Y"!

Validations and control of the database updates is best done by a program on the server side. Business process may need to bend a little in this case, or do the users ease of job preferences stack up as more important than correct business/IT processes. Long run it is cheaper to get users to conform to the system than maintain custom systems that cater to the users ...

Which of course is the longest way I could think of this morning to say i agree with Tom.

[soup_dog]

Re: SNA on V6R1

I agree too. Buuuut... I dont have any choice in the matter. Lets say they have a screen that they have to type a part number into and then press ENTER. That program... tens of thousands of lines of spaghetti code... updates 7 or 8 files, changes a bunch of flags and writes a bunch of audit records. Now lets say the same user has a list of 20000 parts they need to do that for. They dont want to wait 2 weeks while I try to figure out all of the updates, write a new program to enter the data... blah blah blah blah blah.

Instead they record a quick macro which fills in across a row in Excel. then they insert a column where they would normally type a part number. Paste in the 20000 parts down that column and then run the macro. About 5 minutes of work instead of weeks of analysis and testing and implementation.

I hate the whole concept too, but I have to agree with their needs as well. I think this is better than giving them access to sequel and allowing them to go nuts directly on the database. At least with this route there are still using the system screens.