Date:   10/2/97  4:32 PM

RE:     Native Files

> >Right now we can't get AS/400 data to a *STMF in the IFS without doing
> >it manually(File Tranfer via CA/400)  or copy to QDLS then copy to a
> >named directory/stream file.   Why not just let us "Read & Write"
> >to a named directory we created on the IFS like VARPG(hence RPGIV compiler)?


>John, you don't need us to add any extensions to the compiler - you can
>already do this by prototyping the IFS APIs. Ray Bills from Rochester
>gave sessions at Common on using these from RPG and COBOL, and I also
>"stole" his RPG example and handed it out with my "Free-Stuff" handout.
>It's so easy to do I don't see that there's any point in extending the
>language to include it. Besides, the way to handle it would surely be to
>have the OS extended to allow an OVR to be issued to 'point' a regular
>database file at the IFS file - RPG shouldn't need to care.

Hi Jon;

        Ya, I attended his session last year and "Left Early"  after a 
discussion on the CPYTOSTMF and CPY commands not supporting 
FROM & TO field mapping parameters.  If the AS/400 wants the IFS to live
up to its potential, it has to be SEEMLESS.  These commands should be
"Polymorphic"   and the COMMAND ITSELF should do all translating and 
mapping.
   
        Example;  Right now if I run a batch job on the AS/400
(lets say EOM or nightly invoicing) and I want to summarize the information
and populate a file on the IFS lets say a   xxxx.DIF or xxxx.XLS type file
which the users will use the next day in their spreadsheets (or what ever),
I Can't do it easily PERIOD.  Using CPYTOPCD (Which I think believe it or
not was written in RPG,  Imagine RPG code in Rochester,  Do you think 
we could ever get it worked on? :---)   (where was I, oh ya)  CPYTOPCD
allowed you some primitive field to field mapping from AS/400 to a PC
type DOC in QDLS.  

The CPY and CPYTOSTMF says "Single Field" records only or... drop dead. 
NO field mapping inheriently(Is that an OO term? You mean the OS doesn't 
hide its internal idiosyncracies?).   I OBJECT.

If its an INTEGRATED File System I should be able to copy one file 
to another without jumping through hoops.  

(CPYTOPCD Qsys.lib file to QDLS .DOC type then CPYTOSTMF to a named DIR) 

 I sent Ray a letter a year ago on this matter.   He told me he still has
the note on the wall and one of the reasons he did that session. 

Anyway,  Ironically I was keying in RAY's example today at work. 
I really appreciate the examples,  don't get me wrong.  And I think API's
are great things to know.  But,,,,,,,, Jon,,,, C'mon,,,  API's to 
read a file, Hmmmm "THAT'S GREAT"  "NOT" .    Ya,  I'm converted I want
to do ALL my reads that way.  Would I rather have 2 pages of Procedures,
Pointers, "10I 0" and "10U 0" Fields, etc than a stupid old READ or WRITE
statement anytime.

Don't get mad now.  You know I meant that in a nice way.

John Carr

P.S.    Of course OS/400 should be extended to cover the OVR command
and all the rest. BTW If the ORIGINAL developers of the SYS/38 were doing
the coding, it would have been done that way.   I mean the guys that said
a *FILE is a *FILE!!  It will be treated like an object!!!   If you want
to OVR a PRTF (sub-class of *FILE) to a  PF or DSPF (sub-class of *FILE)
then by gosh darn  we will make it transparent to you that there are 
major differences internally. 

  Integrated File System.     Hide the idiosyncracies. 


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].