Re: About Berkeley db-1.85.

You're on MVS, right?

If you were on CMS, I would suggest that you don't use the filesystem
at all, but instead that you access the minidisk cylinders directly.

I believe that this should be possible on VM, although I don't know
anything about the details; but: there are definitions in the VM directory
that define a whole physical disk pack as one large minidisk, overlapping
all the other "user minidisk", and there are utilities that access those
minidisks to do a whole disk dump etc.; so I think VM must have services
to access the blocks of an "unstructured" minidisk. IMO that's what
SQL/DS did; the first relational database system of IBM, if not the first
in general (called System R in the beginning).

And this was in the 1975 time frame, so it should well work on 1979s
VM/370 R6.

Cross-posted to H390-VM...

is there by chance a version of System R available somewhere or an early
version of SQL/DS, which could possibly run on the free VM/370?

Kind regards

Bernd


Am 22.02.2017 um 10:31 schrieb Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[email protected] 
[hercules-os380]:
> On Wed, 22 Feb 2017, Bernd Oppolzer berndoppolzer-/[email protected] [hercules-os380] wrote:
>
>> Am 22.02.2017 um 03:16 schrieb Tony Harminc [email protected]
>> [hercules-os380]:
>>>
>>>   On 21 February 2017 at 20:52, Jon Perryman jperryma-yBeKhBN/[email protected]
>>>   <mailto:jperryma-yBeKhBN/[email protected]> wrote:
>>>
>>>       Sorry Tony, Since Giuseppe specifically mentioned database, I
>>>       thought you saw how it could be very useful for databases.
>>>
>>>
>>>   I've worked on database internals, and I've never seen anything like
>>>   RECFM=U used for the backing store. Sure, if you want to implement your
>>>   own database *in your application program*, then RECFM=U might make some
>>>   sense.
>>>
>>>       Giuseppe is asking for byte level positioning. MVS only provides
>>>       record level positioning.
>>>
>>>
>>>   Well I don't speak for him, but unless I'm greatly mistaken, he's not. He
>>>   wants block level access only, and some existing code (in this case
>>>   Berkeley db) will manage the application data within those blocks. This is
>>>   an extremely common approach; virtually all databases exploit some kind of
>>>   underlying fixed-size block-level storage to support whatever their
>>>   database semantics are. In the current IBM world it's almost invariably
>>>   VSAM ESDS with 4K blocks. Possibly KSDS to manage database indices, or
>>>   maybe they do that themselves too.
>>>
>>>   Tony H.
>>>
>> DB2 indices are manages by DB2 itself in ESDS (or LDS) files;
>> KSDS is not used by DB2 (only one minor exception, IIRC:
>> the master file that controls all the logfiles).
>>
>> And: IIRC, the larger DB2 pagesizes (8k, 16k, 32k) are implemented
>> with 4k CISIZEs, too (taking more of them).
>>
>> And: the transport between system buffer (in main storage)
>> and disk always is 4k pages, no matter how much of the page
>> is used or free. DB2 of course tries to minimize transports between
>> buffer and disk and flushes cache to disk only when necessary.
>> Much more I/O to the log than to tablespaces (ROT).
>>
>> Kind regards
>>
>> Bernd
>>
> Then, let me speak for mylsef ;-) ... better let BDB speak
> of itself ... ;-)
>
> The BDB code requires, if I'm reading correctly these fragments,
> the "core I/O" routines for the btree BDB code (hash is almost the same):
>
> mpool_write:
> off = mp->pagesize * bp->pgno;
>           if (lseek(mp->fd, off, SEEK_SET) != off)
>                   return (RET_ERROR);
>           if (write(mp->fd, bp->page, mp->pagesize) != mp->pagesize)
>                   return (RET_ERROR);
>
> mpool_get:
> off = mp->pagesize * pgno;
>           if (lseek(mp->fd, off, SEEK_SET) != off)
>                   return (NULL);
>           if ((nr = read(mp->fd, bp->page, mp->pagesize)) != mp->pagesize) {
>                   if (nr >= 0)
>                           errno = EFTYPE;
>                   return (NULL);
>           }
>
> that the I/O is done in "pages" of "pagesize", with 512<=pagesize<=65536
> (default 16Kb, configurable at runtime).
>
> As you may read with your eyes, UNIX provides,
> with the "lseek()" syscall "byte level positioning",
> but BDB actually uses "page level positioning", it "converts"
> "byte positioning" in "block positioning", in MVS terminology,
> RECFM=F would fit this case, I guess.
>
> Beside that, BSAM, in UPDAT mode ONLY would be enough
> if and only if the dataset is
>
> a) preallocated
> b) initialized in OUTPUT mode for a fixed number of blocks
> c) never extended beyond its initial number of blocks
> d) each write would actually become a sequence of: POINT,READ,WRITE
>
> or, at "lseek time", I may check for "writing beyond the EOF",
> close the dataset, open it in OUTPUT mode, extend the number
> of blocks, if possible, or return an error and then switch
> again in "UPDAT open mode".
>
> That would requires, of course, a way to know the number of
> blocks at which the dataset was initialized.
>
> A question.
>
> Do you (the list) think I got a correct picture of what
> I may expect from BSAM and how it fit to these BDB I/O
> routines?
>
> Peppe.
>
>



------------------------------------

------------------------------------