Conference iosg::all-in-1_v30

�     1.I have a file with variable length records can ALL-IN-1 map
�	the file with a form  and do I have to define the maximum 
�	length in the FDL ?

	Generally, you cannot do this.  There are some ways to "maneuver"
variable length records, but they all have some shortcomings.  For example, *if*
the "variable" portion of the record is at the end of the record, you could
create a fixed-length entry form to at least map the fixed portion of the
record.  (BTW, don't try this in V3.0, since you'll get an error about the
record size;  V3.0 got a little too "smart" for its own good.)

	If you have total control over the design of the data, you could also
"partition" the record into fixed- and variable- length data; then, you could
use an entry form for the fixed portion, and implement some other mechanism for
the variable portion (much as SCS or SES Time Management Extensions does, by
having a pointer *within* the fixed portion of the record that points to the
variable portion).

	None of this requires an FDL file; in fact, there is nothing you could
do in an FDL file anyway that would circumvent this.  And the worst case, of
course, is if you have little (or no) control over the structure of the data 
file, but must live with whatever you have.

	I'll leave the alternative of using Rdb as another reply for Joe to
fill in...  8^)

�     3. If I can map the file but am intrested in only part of the fields
�	(for example I need to show a specific field) do I HAVE to have 
�	a "dummy" filler-field in order to fill the entire maximum length
�	defined in the FDL ?

	Once you can successfully map the file via an entry form, you can create
an alternate entry form containing only the fields you are interested in.  This
form will point to the original (i.e., full) entry form via the /DATA qualifier
(see Application Programming Reference Volume 1), and you will have exactly
what you need.

	F

>        Generally, you cannot do this.  There are some ways to "maneuver"
>variable length records, but they all have some shortcomings.  For example, *if*
>the "variable" portion of the record is at the end of the record, you could
>create a fixed-length entry form to at least map the fixed portion of the
>record.  (BTW, don't try this in V3.0, since you'll get an error about the
>record size;  V3.0 got a little too "smart" for its own good.)

F,

Thanks for your reply. What I need to do is to loop over an Indexed file
with variable length records in order to display values to the user. The
user then chooses the values from a reguler select form (the same way users
use FIND to choose documents in their DOCDB). The file I am scanning
is created by another application and I can't control it. The variable part
is at the end of the record and I am only interested in the fixed part at the
start. When I tried to map it at first time it was o.k. then, when the file
became big (34,000 records) ALL-IN-1 gave partial information from the file.
In the fdl it was writen that the size of the record is 0. Then I have changed
the fdl definition to the actual maximum length of the record, performed
convert/fdl and it looks o.k. 
Does it make sense, or just pure luck ? Will it fail again ?
My entry form maps only the fixed length fields that I am interested in.

Thanks, Yariv 

    Since you have an existing file to map to, and you only really need
    access to the fixed portion of the record, the following doesn't
    necessarily apply in your case, but I'll include it to keep Frank
    happy! ;-)

    One alternative would be to store your data in an Rdb/VMS database, and
    then use SRA to map to the table.  For variable length text fields,
    just have your entry form use fields that are as long as the maximum
    length of the field.  SRA will handle the truncation of the fields, to
    save space.

    If you need access to variable length fields in RMS files, just add
    RdbAccess for RMS to the above scenario!

    Joe Duncan @ OPA

	Thanks, Joe; I knew you wouldn't fail me!  8^) 

	Just to reiterate one other thing re: the mapping of the RMS file via
an entry form in V2.4:  You can certainly create an entry form that defines only
the fixed portion of the record, and the remainder will be truncated.  *HOWEVER*,
this will *NOT* work in V3.0; you'll get a record size mismatch.  So be careful
with the approach that you take; you may be using an "undocumented feature" that
may not be upgradeable later.

	F

>    One alternative would be to store your data in an Rdb/VMS database, and
>    then use SRA to map to the table.  For variable length text fields,
>    just have your entry form use fields that are as long as the maximum
>    length of the field.  SRA will handle the truncation of the fields, to
>    save space.

Joe,

That's nice but...

There is no Rdb in the application and all the files are RMS files. There
is no need for Rdb and the customers (it is implemented in few large sites)
don't want to add Rdb. 

>
>    If you need access to variable length fields in RMS files, just add
>    RdbAccess for RMS to the above scenario!
>

Any way, to map an RMS file in ALL-IN-1 with Rdb sounds like driving from
New York to Boston via L.A...

The part I can't understand is how ALL-IN-1 handeled the file correctly after
the definition of the maximum length of the record in the fdl. By the way,
how does ALL-IN-1 handle PENDING.DAT, a variable length record ?

Thanks, and sorry to see OPA is closing down.
Yariv

� The part I can't understand is how ALL-IN-1 handeled the file correctly after
� the definition of the maximum length of the record in the fdl.

	As I said earlier, prior to V3.0 ALL-IN-1 wasn't terribly concerned
about matching record lengths.  When it needed to truncate, it did just that.
In V3.0, however, you'll find that it's pickier about doing things like that.

� By the way,
� how does ALL-IN-1 handle PENDING.DAT, a variable length record ?

	PENDING.DAT is never accessed via an entry form.  It is only accessed
via special internal code (a special DSAB) that knows specifically how PENDING
is formatted, and what to do with it.  It's similar to the code that handles
the DAF records.

	F

>
>        As I said earlier, prior to V3.0 ALL-IN-1 wasn't terribly concerned
>about matching record lengths.  When it needed to truncate, it did just that.
>In V3.0, however, you'll find that it's pickier about doing things like that.

Frank,

What does ALL-IN-1 V3.0 do in that case ? Will it genarate an error ?
>
>        PENDING.DAT is never accessed via an entry form.  It is only accessed
>via special internal code (a special DSAB) that knows specifically how PENDING
>is formatted, and what to do with it.  It's similar to the code that handles
>the DAF records.

Suppose I want to write a special "FORIEGN DSAB" to handle those files. All
I need is to "read only" fixed length fields from that indexed, variable
length, RMS files. Is it complicated ? Does the way to do that is documented ?
What would you suggest to do in such a case ? The potensial sales from the
application are impressing, Yet we must have this read only functionality
from those files without changing theire internal structure.

Thanks,
Yariv




    

� What does ALL-IN-1 V3.0 do in that case ? Will it genarate an error ?

	Yes it does.  I believe the wording is something like "Record length
mismatch".  In any case, it won't allow the entry form to be displayed or
processed.

� Suppose I want to write a special "FORIEGN DSAB" to handle those files. All
� I need is to "read only" fixed length fields from that indexed, variable
� length, RMS files. Is it complicated ? Does the way to do that is documented ?
� What would you suggest to do in such a case ? The potensial sales from the
� application are impressing, Yet we must have this read only functionality
� from those files without changing theire internal structure.

	For one thing, you wouldn't want to use anything like the Foreign DSAB,
since that is file-oriented, and doesn't allow individual record access.  (I.e.,
you can't read/write/copy/delete individual data in a Foreign file.)

	Furthermore, files like Pending aren't *truly* variable length.  So the
application you have isn't quite the same thing.  You are really going to have
to (somehow) get your records to be fixed length.  If you have any control at
all over the design, you can do that by splitting the fixed data from the vari-
able data, as mentioned earlier.  If you don't have that control, my next incli-
nation would be to create some kind of "bridge" between the variable length
data and a fixed length data file that you *do* control.  Then use that fixed
length data by ALL-IN-1.

	F

    I think Yariv has a good question.  How difficult is it to write a
    special DSAB in whatever language (BASIC, FORTRAN, etc), that could
    then return field values from the variable field length record?
    
    I've always considered special DSAB writing to be a bit of a Magic art,
    but then I've never really looked into it.  So how hard is it?
    It doesn't seem to be documented anywhere.  Not in the Guide, nor APR1.
    The values could be returned in standard field access syntax, or even
    as symbols or logicals if necessary.
    
    	Bob Halsey, Toronto SWS

    It will, however, be documented soon in a book from Digital Press. 
    Called "ALL-IN-1: Integrating applications with V3.0" (what a great
    title!) by John Rhoton, it covers every aspect of CLI... and lifts a
    great deal of the black art out of the picture.  The book will be
    available in early December.
    
    Tony

>
>    It will, however, be documented soon in a book from Digital Press. 
>    Called "ALL-IN-1: Integrating applications with V3.0" (what a great
>    title!) by John Rhoton, it covers every aspect of CLI... and lifts a
>    great deal of the black art out of the picture.  The book will be
>    available in early December.
>    
>    Tony

We are looking forward to this book. Any way, From what I understood 
in the previous replies, special DSAB will not give the ability to map 
variable length records (even if it is for "read only" purpose of the 
fixed length part of the record). 
Am I right or wrong ? 

Thanks, Yariv 

    I'm not too sure about that... After all, the attributes portion of an
    SDAF/PDAF/PENDING record is variable and ALL-IN-1 manages to read them
    pretty well via the DSAF.  You should be able to write a data set that
    deals with a variable length record.
    
    Tony

    Yariv, Bob,
    
    	If something like SRA can be written, I can't believe writing
    either a special DSAB or one that maps an entry form that supports
    variable length records isn't possible.  In fact it seems like
    it would be quite trivial.
    
    	If one wants to tackle a DSAB that maps an entry form for V2.4, you
    would need a piece of code that SRA and the Remote DSAB uses called
    Data Decide to get your DSAB called.  It uses the .FILE directive
    to get the DSAB called and you can put any other information
    you need on the .FILE directive that you might need to get the
    job done.  Of course, V3.0 supports Data Decide.  
    
    	Yes, a DSAB can be written in FORTRAN, BASIC, etc.  There are 
    BLISS routines that can be used to update/read the DSAB structures so one
    doesn't have to be concerned about accessing the structures directly.
    In fact, I recall a gentleman in Australia wrote a relational DSAB in
    FORTRAN a few years back.
    
    sandy
    
    sandy