Re: System/36 command from a CL?

Hi!

I don't like the way IBM allows the functionality of multiple format file
with X physical files simulating the X different formats of the file and a
file selection program. The ideal solution IMHO is allow multiple formats in
the same physical file, each definition pointing on the same data, and let
the system returns the right format depending on the type code. It is not
possible now... The only clean way I know to convert a S/36 multiple format
file to a native file with DDS is to split the S/36 file into many physical
files that corresponds to the different field definitions...

It is not what I call a pleasant and easy solution...

Charles

"Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx> a écrit
dans le message de news:20060410135027.L2427@xxxxxxxxxxxxxxxxxxxx
>
> > Some people believe that an RPG II program cannot read/update an
> > externally described file.  Even though it must be program described in
> > RPG II, it can be a "flat" file (BLDFILE) or externally described (DDS
> > or SQL).  Go ahead and externally describe it.
>
> The only drawback to externally defining a S/36 file is that S/36 DFU
> programs will no longer work.  If you're using those, you have to create a
> native DFU that works off the external definition.
>
> However, if you have a file with multiple record formats, and you don't
> want to split it into 18 PFs with a multiformat logical to join them, then
> you'll have a hard time creating a DFU.
>
> For example, we had a S/36 file with a record type code in position 1, and
> a key in positions 2-13.  The rest of the record varied depending on what
> the code in position 1 was.  We tried to externally define it with the
> following DDS:
>
>       A                                      UNIQUE
>       A          R MULTFMT
>       A            RECTYPE        1A
>       A            KEY           12A
>       A            VARDATA      115A
>       A          K KEY
>
> Although this worked fine from RPG II programs, or indeed, any RPG program
> that program described the file, it did not work with DFU.  The S/36 DFU
> refused to even attempt to edit it, saying it was a native file.  The
> native DFU would always display VARDATA as one big field, and since it
> contained packed fields, it often wouldn't display the record at all,
> saying that it had illegal characters in it.
>
> Fortunately, this file was only temporary, we ended up completing re-doing
> the file from the ground up, using modern (well, modern at the time)
> techniques.
>
> But, I learned my lesson not to create an external definition just so that
> I could create the file without BLDFILE. :)
>
> Of coruse, when you don't have multiple formats in the file, then it's a
> no-brainer to externally define it.
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email:
MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>