Re: 24x80 size issue

["Anthony Hardy" <mis@xxxxxxxx>]

Thanks for your reply:).

I'm going to double check ptf status (though we loaded the latest cum for
5r1, you never know).

The vendor said the problem was only on OLD dumb terminals and that the only
way they were able to "fix" it was to have thier client (one of about 20)
replace the two terminals causing the issue.

I also called IBM.  They pointed to the coding issue as well, but were
stumped when I mentioned that it worked on all of my other clients (express
5r1 and dumb terminals).

As far as IFS directories . .I wouldn't have the foggiest clue there (I'm
obviously new to the 400 area and am working my way through)  . but I think
I can figure out how to check what moved and what didn't.

I really appreciate your help here and will let everyone know what happens
after I get some other monkeys off my back:).

Anthony
----- Original Message -----
From: "Evan Harris" <spanner@ihug.co.nz>
To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com>
Sent: Tuesday, January 14, 2003 1:58 PM
Subject: Re: 24x80 size issue


> Hi Andy
>
> taking into account the other responses, and not discounting the PTF
issue,
> it seems that something required by the application was stored somewhere
> other than the *ALL USR save.
>
> Since the vendor "hasn't seen this in a long time", this suggests they
have
> some knowledge of what might be missing (I'm guessing that the client is
> specific to their application ?) as they have at least seen it before;
> therefore, hassle them to tell you how it was fixed last time ;)
>
> You may want to consider whether there were some IFS directories that
> should have been transferred, and also check *PGM and *CMD objects in the
> non *ALLUSR libraries by comparing them with listings on the new system.
>
> I wonder also whether you have a job description that needs some changes,
> or perhaps a comms (maybe mode) object. I'm thinking along the lines of
> system objects that are shipped but may have been modified on you original
> system but not the new one. This starts to get into the guts of what your
> vendor should be able to tell you (and makes a case for segregating
> application dependencies). You could be looking for a needle in a haystack
> if you vendor can't help you...
>
> For what it's worth, I think you ought to be able to migrate between boxes
> without relying on a SAVSYS approach, but it does mean that you have to
> know where all the programs - and more importantly the system
> infrastructure those programs depend on - lives in order to be able to
> recreate it.
>
> Regards
> Evan Harris
>
>  > Had a model 600 - upgraded to a 170, all sysvals the same, OS/400
stayed
>  > at 5r1.
>  >
>  > I have some thin clients that worked fine pre-upgrade, but now, post
>  > upgrade, I get an error concerning the "clients" ability to show
>  > fields/data outside of the 24x80 workspace.  Extended display error.
The
>  > third party vendor tells me they haven't seen this in  a LONG time (not
>  > since some VERY old terminals were in use) and that all newer terminals
>  > should be able to handle the way things are NOW.
>  >
>  > Our existing dumb terminals (3477FGs over twin-ax) handle everything
> just
>  > fine, as do our CE sessions.  I'm stumped b/c the thin clients DID work
>  > just fine before the change in AS400s and I am too much of a novice to
> be
>  > able to tell what is happening.  I have manually created devices to see
> if
>  > that is the problem - no.  Autocreate - no.
>  >
>  >
>  > Secondly . . and I'm certain this is tied into the same issue, deals
> with
>  > printing.  I setup a session on the thin clients for printing, manually
>  > create the printer (with model type, etc) and everything was working
>  > great.  We changed systems and now I get what looks like about four
> lines
>  > of ascii column and row "headers" boxing in the correct printout.  The
>  > thin client setup did not change . .and I am stumped.
>  >
>  > Any ideas?
>  >
>  > Thanks!
>  >
>  > Anthony Hardy
>  > Director of MIS
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>