any OS/400 people out there?

[tigerwannabe]

ok, i'm gonna show my age here i'm an AS/400 programmer by trade and was wondering if we have any folks here who are running OS/400 V5R1. we had trouble in the beginning with V5R1 and our ODBC connections to the 400. any other gotchas that folks have found? please feel free to reply with your observations, opinion, etc on OS/400.

 

[Drakkhen]

Well, I am an AS/400 guy, but we are still chugging away with v4r4 with plans to upgrade to v4r5 next month.

Since we may upgrade to v5r1 next year, what kind of problems did you have with the ODBC connections?

 

[Crab cake]

Consider yourselves lucky. We are still running V3R7, but then we also have a few VMS 5.xx as well. Doesn't matter really. Everything is moving to AIX anyway.

 

[tigerwannabe]

well, the deal with ODBC had to do with our drivers. we use a little older version of intersolv ODBC drivers & those were temporarily knocked out when we went to V5R1. i think our sys admin had to upgrade to a new version of intersolv. the WRKSBMJOB command seems to run a little faster, too. if you do journaling, you can do a little more journal performance tuning now. if i think of other things, i'll post them here.

 

[Drakkhen]

Great. Thanks for the heads up!

 

[MGMorden]

Um, I've changed the IP address of an AS/400 . . . that's about it . I'm supposed to be learning how to work one in order to help a professor at the place where I work (and go to school. student worker). I'm not progressing very much though. Only thing I figured out was the IP address thing and that was in a case where they really needed it done before the end of the week so I resorted to Usenet . They really should hire somebody with a certification or at least some formal training to look after this machine but until then I just hope nothing goes too seriously wrong . . .

 

[tigerwannabe]

no problem, Drakkhen

just remember this about a 400, MGMorden: vowels are bad work-related commands are wrk, display commands are dsp, etc. the help system is pretty comprehensive, so it's really not that hard to figure out.
i've been working with the AS/400(or iSeries, if you wanna use IBM's new name) for 7 years now, & i love it; it's a great box.

 

[tigerwannabe]

mainly for Drakkhen...here's a heads-up on OS/400 V5R1 that i just learned. it seems as though compiling a program on V5R1 with the parm tgtrls(*prv) doesn't produce identical code to that compiled on V4R5. i came across this from the iSeries News magazine email list i'm subscribed on. the newsletter doesn't say whether there's a ptf for this. what follows below is the text of the message in the email:


Q: I am trying to create a program from several modules and bind it to a service
program, but I am having problems. For example, consider that I have the
following objects:

Mod1 -- RPGLE module
Mod2 -- SQLRPGLE module
Mod3 -- RPGLE module
MySrvPgm -- Service program consisting of RPGLE module SPMod

I am trying to create program MyPgm with the following command:

CrtPgm Pgm(MyPgm)
Module(Mod1 Mod2 Mod3)
BndSrvPgm(MySrvPgm)

The compile fails in the binding step with message MCH0601, "Space offset or
teraspace offset outside current limit for object."

Is it simply not possible to bind these program objects in the manner I'm
trying?

A: There is nothing wrong with the way you're trying to bind the program
objects. Based on previous experience, I suspect that your problem is related to
previous release support incompatibility. For example, all of your program
objects are compiled to run at release V4R5, but some were created with the V4R5
compiler and others were created with a V5R1 compiler with TgtRls(*Prv) so that
they were compatible with V4R5. This often happens in environments with multiple
systems at different releases. Some objects are compiled on one system (e.g., at
V5R1) with TgtRls(*Prv) and sent to another system with a different release
(e.g., at V4R5). Subsequent changes to the sources of some of these objects
result in a recompile on the V4R5 system specifying TgtRls(*Current). Even though
all objects (those compiled on the V5R1 system and those compiled on the V4R5
system) have a target release of V4R5, they were created with different
compilers. It appears that compiling at V5R1 with TgtRls(*Prv) doesn't produce
identical code to that produced at V4R5.

You should use command DspMod to display modules Mod1, Mod2, and Mod3 and
examine the release at which they were created. You should recompile (on the
V4R5 system) any modules that were created on the V5R1 system. Once all modules
are created by the V4R5 compiler, you will be able to bind them together with
your CrtPgm command.

Note that this is a circumvention only. You should report this problem to your
software support provider, who can determine whether corrective PTFs exist. If
they do not, the problem should be reported to IBM.

 

[Drakkhen]

Thanks again! I am printing that out even as I type

This would definitely have been something that would have taken a while to figure out!