Re: SQL Usage? -- MIDRANGE-L

In some things I am a trainee, trying not to be a klutz.

Yes I use some SQL at work.  For me it is a relatively new language which I 
became exposed to in 1998 when we migrated BPCS/36 to 405 CD & the project 
design was such that until serious pilot testing was done with vanilla BPCS, 
our personnel would not know what they really needed modified, and the 
schedule called for their needs to be implemented 2 months later, using 
programming languages that I had not yet learned, and we had something of the 
order of magnitude of 1,000 modification requests from the project team.  
Obviously something had to give.  Part of the solution was to bring in 
programmers from the consultants who had given us the schedule in the first 
place, one of whom was an SQL enthusiast.  Excuse me for being cynical.

My usage of SQL in software beyond what was involved in that 1998 conversion 
has been SQL embedded within RPG to do stuff that seems to me to be more 
efficient than RPG can do.  As much as possible I try to leave the logic of 
our package intact until I have a level of confidence in using tools that are 
new to me (trainee not want to be klutz).

I do write new programs that are 100% RPG.
I do write new RPG programs in which SQL is used very heavily, with very 
little file access via RPG, and a lot of file access by SQL.
I do work on programs in which 100% file access is via SQL with none of the 
RPG file access methods employed.
Most of my SQL file access is via defining a cursor, then processing a series 
of field clusters much like I would process a series of records from one file 
via RPG READ, except the data is really coming from selected fields from a 
marriage of a bunch of files.
I am working on a program at the moment in which the primary file, accessed 
via RPG, is an IBM *OUTFILE list of statistics about some of our files, then 
using the file names from the IBM *OUTFILE, I use SQL to access those files 
to get at some statistics about their contents, using a technique taught to 
me on this list.

As far as I am concerned, SQL embedded within RPG is a technique, like CHAIN 
READ traditional methods of RPG access is a technique.  I pick & choose what 
seems to be the most useful techniques to solve any given challenge.  I have 
recently written programs that use the RPG Cycle, but most of my writings 
these days do not.

BPCS source code comes from AS/Set which my employer has not given me access 
to.

The tables of BPCS that I work with are DDS source.
The tables that I add for new files, new logicals, new data structures, are 
also DDS source.
DDS is used for report layouts from RPG programs, screen layouts for programs 
& prompt screens, physical files and logical files.  I do not know what SSA 
used to create their data structures, but the new ones I added were via DDS.

I want to leave a legacy in which the source of any package of software with 
my employer does not require technical know-how across a spectrum of 
techniques, or programming languages beyond those required of me, unless 
there has been clear communication with my employer about deliberate addition 
to complexity of skills needed to do the job.  
If when I retire from Central they are still on 405 CD, one of the many 
skills of my replacement will have to be managing layouts using DDS, due to 
the package's source code.  I do not feel especially motivated to complicate 
that area.
One of the nice aspects of OS/400 structure is that objects can be managed by 
people who are skilled in different but not all types of objects, so that 
when a company needs 2 or more MIS people it is only neccessary that their 
total skills encompass all needed, not that each one has them all.

When I add new files, they are by hand using PDM cut & paste pieces of other 
files DDS that have similar requirements to the new file, then copy similar 
lines & alter them.

I have not yet learned any scripting language.

Except some BMRs (software fixes from SSA, the software house that provides 
us with BPCS), our test environment uses the same software as our production 
environment, but has different files, which have been copied from the 
production environment.  It is used for testing that is so sensitive that we 
dare not touch the production environment, however, most of our testing is 
done in the production environment.  

Example ... I might have a new version of the factory work orders.

Typically, testers add to the library list to use the new version & create a 
few using the new software version.  We plan to kill those factory work 
orders, using vanilla BPCS software, after inspecting them to see if the new 
software version is satisfactory.  If the test is not satisfactory, the users 
tell me what the problem is & I work on the new version until it is ready for 
another test.  If the users are happy, I am instructed to move the new 
version into the production software.

>  From:    david@midrange.com (David Gibbs)
>  
>  Folks:
>  
>  I'm doing some research on how AS400 users use SQL ... perhaps I could get 
>  some questions answered ...
>  
>  1. Do you use SQL for AS400 based application development?
>  
>  2. If (1) is No, why not?  [If (1) is no, you can skip the rest of the 
>  questions]
>  
>  3. How do you create tables for development?  Scripts in source PF's?  By 
>  hand?  Programs?  Other (please describe)?
>  
>  4. If you use scripts in source pf's, do you create a single table per 
>  script or multiple tables per script?
>  
>  5. Do you recreate the tables in your production environment or move them 
>  from your development environment?

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---