[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

2214.0. "CHECKING THE RECORD LENGTH WHEN USING ENTRY FORMS" by TAV02::SHAPIRA () Thu Feb 04 1993 15:29

Hi,

This question refers to both V2.4 & V3.0

In ALL-IN-1 v2.4 no check was done between the record length of a record mapped
by an ENTRY FORM, and its real length in the file.

In V3.0 a check is made. If ALL-IN-1 finds a difference between the lengths it
issues a "record length mismatch" error.

My questions:

1. Is there a deep reason that forced engineering to activate such a check ?

2. How this check is implemented in the code ?. Can I omit the check for a
special form ? In V2.4 many programmers used special ENTRY FORMS to map
variable length records in order to read fixed length fields from those files.
I would like to give them the same functionality in V3.0 without causing any
demage (I know that it wasn't offcially supported (but in the same time it is
not written in the docs of 2.4 that ENTRY forms are restricted for fixed length
records) but I must give a solution for many sites that want to upgrade their
system to 3.0).  

3. Does the check is performed on a record base or file base, i.e does ALL-IN-1
checks the file header or does it check each record for its length ?

Thanks for any help,
Yariv
T.RTitleUserPersonal
Name		DateLines
2214.1It was done to fix a bug; you may be able to avoidIOSG::SHOVEDave Shove -- REO2-G/M6Thu Feb 04 1993 16:5229
    I've looked at the revision history, and the code of the relevant
    module (OARMS.BLI), and the answers seem to be:
    
    1. The check was inserted to fix a bug.
    
    3. The check is done on the file header - see below.
    
    2. According to the code, it will only make the check if the file is
    marked as having fixed length records (RMS header field FAB$B_RFM =
    FAB$C_FIX). If RMS says it has variable length records, the check
    shouldn't be made - this might be the way out of your problem.
    
    Also, the check is only for file's-record-length (RMS header field
    FAB$W_MRS) < entry-form-length (the bug concerned writing to fields in
    the entry-form which were off the end of the physical record). So an
    entry-form which is smaller than the physical record should be OK.
    
    Also, the check is only done for "normal" RMS data-sets (the code
    checks that the action routine = OA$RMS_ACTION). So, if you do need to
    over-ride the check, all you should have to do is to supply a DSAB (use
    the ones in OAGBL.BLI to see how they're written) specifying a new
    action routine you write, which does absolutely nothing except to call
    the normal OA$RMS_ACTION (with the same parameter, of course). This
    should cause the check to be skipped, according to my reading of the
    code.
    
    Dave 
    
    (PS - for IOSG use - Time case THR-13425, Diamond ICO #1572, by EC)
2214.2We will check it with variable length recordsTAV02::SHAPIRAFri Feb 05 1993 13:2914
Dave,

I'm very pleased from your reply. I will forward it to local engineering and
customer service. We meet on monday morning to discuss the problem and as I
understand it should work with variable length records the same way it worked
in V2.4.

At the same time I've started to look into the DSAB solution with the help of
Jhon Rhoton and his book (highly recomended, as well as Tony Redmond's new
one).

Thanks, Yariv
2214.3It is working just fine !!TAV02::SHAPIRASun Feb 07 1993 15:1515
Dave,

I have just tested an entry form mapping a variable length record file, and it
is working fine !

I was able to read records from the file, as well as update record using the
entry form.

So, if anyone used entry forms to map variable length records in V2.4 he can
relax as it is working the same way for V3.0.

Now I can move into the real thing - migrating the CLI to V3.0.

Thanks for help,
Yariv