Technology shifts (was RE: Performance of SQL)

rpg400-l-request@xxxxxxxxxxxx wrote:

>I am (trying to) use free-form specs finally, but I am having some
>difficulty performing date functions.  I figured out that I can use the
>%DAYS/%MONTHS, etc. BIFs for date arithmetic, but when I want to extract the
>date to an alpha field, MOVE is the only way I know of, except for using the
>%SUBDT, then converting each component to an alpha sub-field component of a
>DS, etc. etc.  This way seems clunky to me, and so my solution, for now, is
>to /End-Free, MOVE the date into the alpha field, then re- /FREE again
>(messy).  Isn't there a way to alpha-ize a date field in free form specs? 

This is not a criticism of the technique nor the technology (nor an answer to 
the question), but merely personal comment. Curious if others have comments. 
This is regardless of whether a %char() BIF is suitable or whether anything at 
all is.

The scenario above comes from the transition from one "technology" to another 
-- column-oriented to free-form as well as DATE/TIME representations to CHAR 
representations. It involves an attempt to bridge between them. One simple 
question is why is there a need to convert to CHAR at all? DB2/400 has date 
fields, DSPFs have date fields, RPG has date fields, etc. One obvious answer is 
that there are existing DSPFs and PFs that require CHAR; they can't efficiently 
be changed right now, so the programmer is stuck with them -- for now.

A similar scenario shows up over and over: "I want to use SNDDST to send to my 
Internet e-mail account. Why is it so hard?" Well, it's not because configuring 
and sending SMTP from iSeries is particularly hard; it's commonly because the 
bridge between SNA/DS and SMTP is a technology bridge. Both technology 
solutions must be correctly configured, making the overall task more than twice 
as hard.

There weren't that many sites that had really 'correct' SNA configurations to 
begin with and an awful lot of TCP/IP configurations had/have minor errors. 
While used with existing, known application functions, either might tolerate 
configuration quirks. But add a new, unfamiliar TCP/IP server, and now you're 
accessing a possible bit of configuration that didn't matter before.

Many single-site AS/400s never really used SNA/DS anyway, so who knew? For 
those sites, when TCP/IP became native under OS/400, one obvious solution was 
to ignore SNDDST and download and install something like SendMail or whatever 
freeware was available. Only when they decided to involve SNDDST and the 
SNA/SMTP bridge did troubles really show up.

Transitioning from twinax terminals to TN5250, from terminal to client/server, 
from thick- to thin-client, RPG to JAVA, OPM to ILE, native I/O to SQL, 
wide-open to CFINT-constrained, Client Access folders to Netserver Windows 
Network Neighborhood, QDLS to root... It seems the iSeries community is in the 
midst of transition on transition on transition. I'm not at all sure how many 
are going on across the community. (V5R3 around the corner...)

Yet, it _still_ seems to be a marvelous platform to develop on.

Tom Liotta


-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com



__________________________________________________________________
Introducing the New Netscape Internet Service. 
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need. 

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp