BASIC : Updating a sequential file causes run time error SIZRECINV (156)

[Robert Nelson]

Hello all
I am trying to update a sequential file with variable record lengths and get the error 156 (SIZRECINV).

Here are the details.

1. Opened file like so
OPEN MYFILE FOR INPUT AS FILE #100% &
ORGANIZATION SEQUENTIAL, RECORDTYPE ANY, ACCESS UPDATE, ALLOW NONE

File opened successfully.

2. read successfully
GET #100%
MOVE FROM #100%, MYREC=RECOUNT


3. TEST_STR = "1234"
NEWLEN = LEN(MYREC) + LEN(TEST_STR)

4. Update fails
MOVE TO #100%, MYREC, TEST_STR
UPDATE #100%, COUNT NEWLEN

I get the error when I attempt to perform the update.

Any ideas?

Thanks

[Jan-Erik Soderholm]

SIZRECINV, Size of record invalid (ERR=156)

Explanation: The program contains a COUNT or RECORDSIZE
specification that is invalid because:

- COUNT equals zero.
- COUNT exceeds the maximum size of the record.
- COUNT conflicts with the actual size of the current record
during a sequential file UPDATE on disk.
- COUNT does not equal the record size for fixed format records.
- You specified a record size in the OPEN statement that was
unequal to the actual record size established when the file
was created.


User Action: Supply a valid COUNT value in the PUT or UPDATE statement
or a valid RECORDSIZE in the OPEN statement, whichever is applicable.

[Robert Nelson]

> User Action: Supply a valid COUNT value in the PUT or UPDATE statement
> or a valid RECORDSIZE in the OPEN statement, whichever is applicable.

Thanks Jan. I have already read up on this error. I believe I am specifying the new size in the UPDATE clause. As for RECORDSIZE in OPEN, the OPEN statement in the REFERENCE MANUAL states that BASIC retrieves the record size value from the file while opening existing files if not explicitly specified.

The file in question will have variable record lengths.

Thanks

[Jan-Erik Soderholm]

OK, I know very little about BASIC och it's RMS functions, but
I'd begin with a few debug printouts of the variable values so
that they can be verified.

[Paul Sture]

You cannot change the size of a record in a sequential file via an UPDATE.

Think about it:

o - if increasing the size, where does the extra space come from?
o - if decreasing the size, what happens to the remaining space?

You can change the record size via an update with indexed files, but not
sequential ones.

--
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.

[Paul Sture]

On 2016-06-03, Paul Sture <nos...@sture.ch> wrote:
> On 2016-06-03, Robert Nelson <2621...@gmail.com> wrote:
>>
>>> User Action: Supply a valid COUNT value in the PUT or UPDATE statement
>>> or a valid RECORDSIZE in the OPEN statement, whichever is applicable.
>>
>> Thanks Jan. I have already read up on this error. I believe I am
>> specifying the new size in the UPDATE clause. As for RECORDSIZE in
>> OPEN, the OPEN statement in the REFERENCE MANUAL states that BASIC
>> retrieves the record size value from the file while opening existing
>> files if not explicitly specified.
>>
>> The file in question will have variable record lengths.
>>
>
> You cannot change the size of a record in a sequential file via an UPDATE.
>
> Think about it:
>
> o - if increasing the size, where does the extra space come from?
> o - if decreasing the size, what happens to the remaining space?
>
> You can change the record size via an update with indexed files, but not
> sequential ones.

I forgot to mention. This is an RMS restriction, and not specific to BASIC.

[VAXman-]

In article <bb082d-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>On 2016-06-03, Robert Nelson <2621...@gmail.com> wrote:
>>
>>> User Action: Supply a valid COUNT value in the PUT or UPDATE statement
>>> or a valid RECORDSIZE in the OPEN statement, whichever is applicable.
>>
>> Thanks Jan. I have already read up on this error. I believe I am
>> specifying the new size in the UPDATE clause. As for RECORDSIZE in
>> OPEN, the OPEN statement in the REFERENCE MANUAL states that BASIC
>> retrieves the record size value from the file while opening existing
>> files if not explicitly specified.
>>
>> The file in question will have variable record lengths.
>>
>
>You cannot change the size of a record in a sequential file via an UPDATE.
>
>Think about it:
>
>o - if increasing the size, where does the extra space come from?
>o - if decreasing the size, what happens to the remaining space?
>
>You can change the record size via an update with indexed files, but not
>sequential ones.

;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Dirk Munk]

Paul Sture wrote:
> On 2016-06-03, Robert Nelson <2621...@gmail.com> wrote:
>>
>>> User Action: Supply a valid COUNT value in the PUT or UPDATE statement
>>> or a valid RECORDSIZE in the OPEN statement, whichever is applicable.
>>
>> Thanks Jan. I have already read up on this error. I believe I am
>> specifying the new size in the UPDATE clause. As for RECORDSIZE in
>> OPEN, the OPEN statement in the REFERENCE MANUAL states that BASIC
>> retrieves the record size value from the file while opening existing
>> files if not explicitly specified.
>>
>> The file in question will have variable record lengths.
>>
>
> You cannot change the size of a record in a sequential file via an UPDATE.
>
> Think about it:
>
> o - if increasing the size, where does the extra space come from?
> o - if decreasing the size, what happens to the remaining space?
>
> You can change the record size via an update with indexed files, but not
> sequential ones.
>

No you can't, only if the file has been defined with a variable record
size. The same applies to relative files. It has been a long time since
I worked with these kind of files, but I assume you will have to declare
a maximum recordsize when creating the file.

[Neil Rieck]

Wow. Some old-school programming here since I haven't seen anyone use "MOVE FROM" or "MOVE TO" since the VAX days. Even then, DEC recommended that everyone use a map reference in the open statement.

In your case, "LINPUT #100, junk$" and "PRINT #100, junk$" might be better alternatives.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/demo_vms_html/openvms_demo_index.html#fileio

[seasoned_geek]

On Friday, June 3, 2016 at 3:03:25 AM UTC-5, Robert Nelson wrote:
>
> 3. TEST_STR = "1234"
> NEWLEN = LEN(MYREC) + LEN(TEST_STR)
>
> 4. Update fails
> MOVE TO #100%, MYREC, TEST_STR
> UPDATE #100%, COUNT NEWLEN
>
> I get the error when I attempt to perform the update.
>
> Any ideas?
>
> Thanks

I realize this is ancient, but I was feeling nostalgic. (I haven't seen direct channel operations since BASIC on the PDP!)

One cannot change the size of a record within a sequential file, especially if the file has record and block spanning enabled.

Were this an indexed file I believe Neil would be correct that you need a MAP. The other alternative is to doe something like, LONGER_REC = MYREC + TEST_STR and use LONGER_REC in your MOVE. I vaguely remember some issue with multiple strings on the MOVE during the PDP era.

I assume an in-place update is being attempted because the record needs to be expanded, but, why do an in-place update? Not enough disk space to read from one file and write to another?

Question: Is this a lookup/reference file or did someone actually design a production system that routinely updates sequential files?