Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Speeding AS400 side of ADV.36

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Speeding AS400 side of ADV.36

    Several suggestions in order of most prefereable to least... 1. Replace the 436 with a Model 170. If this is feasable budget wise. These newer machines are quite a bit faster than the 436. 2. Add more memory and possibly more DASD. OS/400 takes up around 4gb which leaves only 2gb for your SSP and user libraries. 3. Have someone who knows about AS/400 performance tuning look at your system. There maybe some things that can be done with tuning of controlling subsystems, communications, etc.

  • #2
    Speeding AS400 side of ADV.36

    A point to remember... If you came to the SSP using TFRM36 you can run most commands that you have authority to on OS/400. If you came to the SSP using PASSTHRU then the command will run under the user profile of the M36, usually QUSER. Also, with a PASSTHRU session you can't run any commands that output to the display station. I'm not sure, but if you run the // RUN400 statement from a workstation that is 'controlled' by the SSP then my guess is that it will run with the QUSER profile but can display OS/400 output. Generally I prefer to use the TFRM36 method of getting to the SSP for a number of reasons, including the ability to run AS/400 commands using the user's profile. Also, a large number of PASSTHRU sessions has a performance impact.

    Comment


    • #3
      Speeding AS400 side of ADV.36

      Virtual devices on the AS/400 cannot be mapped to the SSP. What you need to do is configure the SSP to have workstations on the second, third or even fourth controller, even though this is not mapped to a real controller. For those people using virtual deviecs (ie Client Access) you need to have them sign on to the AS/400 and run a small CL program that will transfer them to the SSP using the TFRM36 command. This program can be set up in their user profiles or on a menu. Personally, I prefer to use device mapping rather then controller mapping and have everyone sign on to the AS/400. However, the one problem of using TFRM36 is that you can't guarantee that the same user will get the same SSP device. This may impact your programs if they use the workstation ID as say part of a batch file name/number. You can write a more sophisticated program to look up user ID's and AS/400 device ID's to obtain a S/36 device ID. However, it is not unusual for LAN users to have two or three sessions open at once, so you will have to consider this also. In the long term (or even short term) you should be looking at migrating to either the S/36 or Native Environments on the AS/400.

      Comment

      Working...
      X