Re: [hercules-os380] About Berkeley db-1.85.

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
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 [hidden email]
[hercules-os380]:

> On Wed, 22 Feb 2017, Bernd Oppolzer [hidden email] [hercules-os380] wrote:
>
>> Am 22.02.2017 um 03:16 schrieb Tony Harminc [hidden email]
>> [hercules-os380]:
>>>
>>>   On 21 February 2017 at 20:52, Jon Perryman [hidden email]
>>>   <mailto:[hidden email]> 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.
>
>



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

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


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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/H390-VM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/H390-VM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
Hello!
I'll allow you the cross-post....
I agree. Is there a copy of SQL/DB that did indeed make it to become
freely available?
-----
Gregg C Levine [hidden email]
"This signature fought the Time Wars, time and again."


On Wed, Feb 22, 2017 at 5:39 AM, Bernd Oppolzer
[hidden email] [H390-VM] <[hidden email]> wrote:

> 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 [hidden email]
> [hercules-os380]:
>> On Wed, 22 Feb 2017, Bernd Oppolzer [hidden email] [hercules-os380] wrote:
>>
>>> Am 22.02.2017 um 03:16 schrieb Tony Harminc [hidden email]
>>> [hercules-os380]:
>>>>
>>>>   On 21 February 2017 at 20:52, Jon Perryman [hidden email]
>>>>   <mailto:[hidden email]> 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.
>>
>>
>
>
>
> ------------------------------------
>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 2/22/2017 11:39 AM, Bernd Oppolzer [hidden email] [H390-VM]
wrote:

> 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
>
It's a bit more complicated than that....

SQL/DS or DB2 on VM uses a method (*BLOCKIO IUCV System Service) to
access the blocks directly outside the CMS filesystem that is not
available on VM/370 (IUCV only became available in VM/SP 3 I think).
     The *BLOCKIO system service allows accessing a specific record
asynchronously without having to deal with the specifics of the DASD
geometry... (it assumes however the minidisk is formatted with 4K records).
     CMS provides with VM providing the *BLOCKIO system service a method
during CMS format to indicate the extents that are available for
*BLOCKIO - basically untouched by CMS - or rather extents in which CMS
won't allocate control structures.

Using a minidisk using Cylinder/Head/Record is possible without
dedicating a volume to the virtual machine (a minidisk in a virtual
machine acts exactly the same as the underlying device type.. Just not
with the same number of cylinders). However doing this on a CMS minidisk
is risky ! However there is no problem defining a minidisk to a virtual
machine and use it as you wish (it just shouldn't be owned by CMS - that
is the 'ACCESS' CMS command shouldn't be used then - except for NON CMS
minidisks - such as DOS or VSAM volumes & such). Nothing prohibits you
from issuing DASD I/O directly to a minidisk !

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
Am 22.02.2017 um 17:19 schrieb Ivan Warren [hidden email] [H390-VM]:

>
>
> On 2/22/2017 11:39 AM, Bernd Oppolzer [hidden email]
> [H390-VM] wrote:
>>
>> 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
>>
> It's a bit more complicated than that....
>
> SQL/DS or DB2 on VM uses a method (*BLOCKIO IUCV System Service) to
> access the blocks directly outside the CMS filesystem that is not
> available on VM/370 (IUCV only became available in VM/SP 3 I think).
>     The *BLOCKIO system service allows accessing a specific record
> asynchronously without having to deal with the specifics of the DASD
> geometry... (it assumes however the minidisk is formatted with 4K
> records).
>     CMS provides with VM providing the *BLOCKIO system service a
> method during CMS format to indicate the extents that are available
> for *BLOCKIO - basically untouched by CMS - or rather extents in which
> CMS won't allocate control structures.
>
> Using a minidisk using Cylinder/Head/Record is possible without
> dedicating a volume to the virtual machine (a minidisk in a virtual
> machine acts exactly the same as the underlying device type.. Just not
> with the same number of cylinders). However doing this on a CMS
> minidisk is risky ! However there is no problem defining a minidisk to
> a virtual machine and use it as you wish (it just shouldn't be owned
> by CMS - that is the 'ACCESS' CMS command shouldn't be used then -
> except for NON CMS minidisks - such as DOS or VSAM volumes & such).
> Nothing prohibits you from issuing DASD I/O directly to a minidisk !
>
> --Ivan
>
Thank you very much ...

But System R has been developped in the 1975 to 1977 time frame;
using PL/I, IIRC- and on VM (maybe DOS/VS - but I'm not sure about
that, maybe VM only). So they must have used another technique
than that IUCV BLOCKIO - if it was not available then.

Does somebody know?

 From what I heard, it was never shipped as a product; only selected
customers got it (Boeing ...) and they also contributed and made
suggestions (I heard that the LIKE condition and WHERE EXISTS
were suggestions of early customers).

But apart from that BLOCKIO physics, it must have been very similar
to SQL/DS. And maybe, if it still existed somewhere today, it should
run on the 1979s VM.

Kind regards

Bernd



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

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


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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/H390-VM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/H390-VM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
From what I heard, System R was extensively used at Pratt and Whitney in
the 1977 timeframe.


Joe

On Wed, Feb 22, 2017 at 11:07 AM, Bernd Oppolzer [hidden email]
[H390-VM] <[hidden email]> wrote:

> Am 22.02.2017 um 17:19 schrieb Ivan Warren [hidden email] [H390-VM]:
> >
> >
> > On 2/22/2017 11:39 AM, Bernd Oppolzer [hidden email]
> > [H390-VM] wrote:
> >>
> >> 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
> >>
> > It's a bit more complicated than that....
> >
> > SQL/DS or DB2 on VM uses a method (*BLOCKIO IUCV System Service) to
> > access the blocks directly outside the CMS filesystem that is not
> > available on VM/370 (IUCV only became available in VM/SP 3 I think).
> >     The *BLOCKIO system service allows accessing a specific record
> > asynchronously without having to deal with the specifics of the DASD
> > geometry... (it assumes however the minidisk is formatted with 4K
> > records).
> >     CMS provides with VM providing the *BLOCKIO system service a
> > method during CMS format to indicate the extents that are available
> > for *BLOCKIO - basically untouched by CMS - or rather extents in which
> > CMS won't allocate control structures.
> >
> > Using a minidisk using Cylinder/Head/Record is possible without
> > dedicating a volume to the virtual machine (a minidisk in a virtual
> > machine acts exactly the same as the underlying device type.. Just not
> > with the same number of cylinders). However doing this on a CMS
> > minidisk is risky ! However there is no problem defining a minidisk to
> > a virtual machine and use it as you wish (it just shouldn't be owned
> > by CMS - that is the 'ACCESS' CMS command shouldn't be used then -
> > except for NON CMS minidisks - such as DOS or VSAM volumes & such).
> > Nothing prohibits you from issuing DASD I/O directly to a minidisk !
> >
> > --Ivan
> >
> Thank you very much ...
>
> But System R has been developped in the 1975 to 1977 time frame;
> using PL/I, IIRC- and on VM (maybe DOS/VS - but I'm not sure about
> that, maybe VM only). So they must have used another technique
> than that IUCV BLOCKIO - if it was not available then.
>
> Does somebody know?
>
>  From what I heard, it was never shipped as a product; only selected
> customers got it (Boeing ...) and they also contributed and made
> suggestions (I heard that the LIKE condition and WHERE EXISTS
> were suggestions of early customers).
>
> But apart from that BLOCKIO physics, it must have been very similar
> to SQL/DS. And maybe, if it still existed somewhere today, it should
> run on the 1979s VM.
>
> Kind regards
>
> Bernd
>
>
>
> ------------------------------------
>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 2/22/2017 6:07 PM, Bernd Oppolzer [hidden email] [H390-VM]
wrote:

> Am 22.02.2017 um 17:19 schrieb Ivan Warren [hidden email] [H390-VM]:
>>
>> On 2/22/2017 11:39 AM, Bernd Oppolzer [hidden email]
>> [H390-VM] wrote:
>>> 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
>>>
>> It's a bit more complicated than that....
>>
>> SQL/DS or DB2 on VM uses a method (*BLOCKIO IUCV System Service) to
>> access the blocks directly outside the CMS filesystem that is not
>> available on VM/370 (IUCV only became available in VM/SP 3 I think).
>>      The *BLOCKIO system service allows accessing a specific record
>> asynchronously without having to deal with the specifics of the DASD
>> geometry... (it assumes however the minidisk is formatted with 4K
>> records).
>>      CMS provides with VM providing the *BLOCKIO system service a
>> method during CMS format to indicate the extents that are available
>> for *BLOCKIO - basically untouched by CMS - or rather extents in which
>> CMS won't allocate control structures.
>>
>> Using a minidisk using Cylinder/Head/Record is possible without
>> dedicating a volume to the virtual machine (a minidisk in a virtual
>> machine acts exactly the same as the underlying device type.. Just not
>> with the same number of cylinders). However doing this on a CMS
>> minidisk is risky ! However there is no problem defining a minidisk to
>> a virtual machine and use it as you wish (it just shouldn't be owned
>> by CMS - that is the 'ACCESS' CMS command shouldn't be used then -
>> except for NON CMS minidisks - such as DOS or VSAM volumes & such).
>> Nothing prohibits you from issuing DASD I/O directly to a minidisk !
>>
>> --Ivan
>>
> Thank you very much ...
>
> But System R has been developped in the 1975 to 1977 time frame;
> using PL/I, IIRC- and on VM (maybe DOS/VS - but I'm not sure about
> that, maybe VM only). So they must have used another technique
> than that IUCV BLOCKIO - if it was not available then.
>
> Does somebody know?
>
>   From what I heard, it was never shipped as a product; only selected
> customers got it (Boeing ...) and they also contributed and made
> suggestions (I heard that the LIKE condition and WHERE EXISTS
> were suggestions of early customers).
>
> But apart from that BLOCKIO physics, it must have been very similar
> to SQL/DS. And maybe, if it still existed somewhere today, it should
> run on the 1979s VM.
>
> Kind regards
>
> Bernd
>
>
I wouldn't know...

But possibly it could run under CMS if System/R did its own I/O - but I
don't see why it would required a dedicated volume !

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
System R was initially developed for VM but required a couple of modifications to VM itself. I believe one was called the Inter User Communication Facility (which may have made it into VM in the late 70s) and the other was Dynamic Writable Shared Segments (DWSS). So far as I can recall, it used standard VM IO to the minidisks but I don't recall how the minidisks had to be configured. The VM version was tested at a couple of customer sites and many IBM sites.

In 1977 - 1978, an MVS version was built for testing and evaluation at Boeing. It used VSAM Control Interval processing to VSAM ESDS data sets and an SVC to provide cross memory post/wait. Boeing was the customer who requested a pattern matching capability which became the LIKE predicate. As I dimly recall, EXISTS came about to solve a performance problem with query processing when all you really needed to know was if a sub-query found results and not what they were.

System R as you probably know was built as two major components. The Relation Data System (RDS) provided the SQL support and query processing and was written primarily in PL/I with assembler and a tiny amount of PL/S. The Research Storage System (RSS) provided data and index management, logging, recovery, and transaction support and was written mostly in PL/S with some assembler.

At the end of the System joint study, each customer was given a copy of the source code and 2 weeks of internals education but no PL/S compiler. I cannot recall if the source code included the PL/S generated assembler.

If you can find the source code, you may get it to run on the VM/370 which is available on Hercules or even MVS 3.8J but you may incur the wrath of IBM legal.

There was a System R Reunion in 1995 and there is a transcript somewhere on the web.

Jim
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list


On 2/23/2017 2:43 PM, [hidden email] [H390-VM] wrote:
>
>
> System R was initially developed for VM but required a couple of
> modifications to VM itself. I believe one was called the Inter User
> Communication Facility (which may have made it into VM in the late
> 70s) and the other was Dynamic Writable Shared Segments (DWSS).
I can assure you IUCV is not available on VM/370 !

--Ivan

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
Each file in a UNIX file system is a byte addressable flat storage
medium.  VSAM ESDS is as close as you will find such an implementation
in MVS.  Each ESDS data set is a flat byte addressable storage medium.
You are just restricted to specific byte addresses, just as the
underlying UNIX file system is restricted to disk sector accesses.

Each ESDS record could be the size of your 'page' and you could use
relative byte addressing to access the index page.  Let VSAM handle all
of the complexity of physical disk record I/O.

Depending upon how the database records are stored, you might need to
provide a more robust mechanism based on the assumption that records
might span pages when actually retrieving or writing records.  But it is
achievable.

I would recommend you pursue this possibility if you are serious about
porting the database.

Harold Grovesteen


On Thu, 2017-02-23 at 13:43 +0000, [hidden email] [H390-VM]
wrote:
>

> In 1977 - 1978, an MVS version was built for testing and evaluation at
> Boeing. It used VSAM Control Interval processing to VSAM ESDS data
> sets and an SVC to provide cross memory post/wait.

>  
> Jim


Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
It was Jensen's VMCF--Virtual Machine Communications Facility.

On 02/23/2017 03:19 PM, Ivan Warren [hidden email] [H390-VM] wrote:

> I can assure you IUCV is not available on VM/370 !
>
> --Ivan
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list


On 2/23/2017 4:48 PM, 'John P. Hartmann' [hidden email] [H390-VM]
wrote:
> It was Jensen's VMCF--Virtual Machine Communications Facility.
>
> On 02/23/2017 03:19 PM, Ivan Warren [hidden email] [H390-VM] wrote:
>
>> I can assure you IUCV is not available on VM/370 !
>>
>> --Ivan
>
VMCF and IUCV are 2 very different beasts !

What SQL/DS, DB2 use(d) is access CP system services (the IUCV *BLOCKIO
system service - which won't work with VMCF).

VMCF has no notion of a path... It is basically a connection-less
communication method (communication between 2 virtual machines) while
IUCV is a connection full software device which allows a software define
service to communicate with another software defined service (within the
same VM, another VM or the hypervisor). APPC/TSAF extends this cross
system (using VTAM PU5 Subareas,  2.1 PUs and LU 6.2 LUs).

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
If you Google "A SHARED SEGMENT AND INTERPROCESS COMMUNICATION FACILITY FOR VM/370" you will find the description for what was built for System R.

 Jim
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
---In [hidden email], <h.grovsteen@...> wrote :

> Each file in a UNIX file system is a byte addressable flat storage
> medium. VSAM ESDS is as close as you will find such an implementation
> in MVS.

I consider RECFM=U on MVS to be the
equivalent of Unix files. Sure, it stores
data in blocks instead of sectors, but in
both cases I expect the programmer to
be shielded from such a difference, ie
whether RECFM=U files are using
6233-byte blocks or Unix is using
512-byte sectors.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
A paper on System R:

https://people.eecs.berkeley.edu/~brewer/cs262/SystemR.pdf

> 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

- Richard
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
On 24/02/17 02:00, Richard Chycoski [hidden email] [H390-VM] wrote:
>
> A paper on System R:
>
> https://people.eecs.berkeley.edu/~brewer/cs262/SystemR.pdf

"Installation of a multiuser database system under VM/CMS required
certain modifications to the operating system in support of
communicating virtual machines and writable shared virtual memory."
[Gray, J.N., and Watson, V. A shared segment and inter-process
communication facility for VM/370.]

Was this IUCV?

I ask only out of curiosity, since I appreciate that IUCV isn't in
VM/370 (as available) or in Hercules. However it is supported to some
extent by the defunct Sim390, which apparently uses it to provide
networking to MUSIC/SP.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list

> Was this IUCV?
>
> I ask only out of curiosity, since I appreciate that IUCV isn't in
> VM/370 (as available) or in Hercules. However it is supported to some
> extent by the defunct Sim390, which apparently uses it to provide
> networking to MUSIC/SP.
>
Implementing the B2F0 instruction is just a matter of coding it ;)

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
On Fri, 2017-02-24 at 01:14 +0000, [hidden email] [H390-VM]
wrote:

> ---In [hidden email], <h.grovsteen@...> wrote :
>
> > Each file in a UNIX file system is a byte addressable flat storage
> > medium. VSAM ESDS is as close as you will find such an implementation
> > in MVS.
>
> I consider RECFM=U on MVS to be the
> equivalent of Unix files. Sure, it stores
> data in blocks instead of sectors, but in
> both cases I expect the programmer to
> be shielded from such a difference, ie
> whether RECFM=U files are using
> 6233-byte blocks or Unix is using
> 512-byte sectors.
>
> BFN. Paul.
>
Quite right.

The question is "Who provides the shielding of the programmer from the
underlying hardware?"  Something like PDPCLIB can do it.  Whether it has
everything needed for the Berkeley DB is a different question.

But if you have to roll-your-own, something that already is  a close
abstraction to what you need and already hides some of the gory details
from the programmer is a better starting point.  That was all I was
getting at.

Harold

Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
I thought some one had some Hercules patches to allow Music IUCV to work...

http://hercules390.996247.n3.nabble.com/TCP-IP-networking-via-IUCV-td48029.html

Dave

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 24 February 2017 14:44
> To: [hidden email]
> Subject: Re: [H390-VM] Re: [hercules-os380] About Berkeley db-1.85.
>
>
> > Was this IUCV?
> >
> > I ask only out of curiosity, since I appreciate that IUCV isn't in
> > VM/370 (as available) or in Hercules. However it is supported to some
> > extent by the defunct Sim390, which apparently uses it to provide
> > networking to MUSIC/SP.
> >
> Implementing the B2F0 instruction is just a matter of coding it ;)
>
> --Ivan


Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
On 24/02/17 17:30, Ivan Warren [hidden email] [H390-VM] wrote:

>
>> Was this IUCV?
>>
>> I ask only out of curiosity, since I appreciate that IUCV isn't in
>> VM/370 (as available) or in Hercules. However it is supported to some
>> extent by the defunct Sim390, which apparently uses it to provide
>> networking to MUSIC/SP.
>>
> Implementing the B2F0 instruction is just a matter of coding it ;)
>
> --Ivan

True. The distinction however is that Sim390 appears to not just
implement B2F0 as an opcode, but intercepts control and provides the
networking stuff. And while the source appears to have been lost,
there's surviving notes on that API.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


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

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


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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/H390-VM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/H390-VM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Reply | Threaded
Open this post in threaded view
|

Re: [hercules-os380] About Berkeley db-1.85.

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
On 24/02/17 18:30, [hidden email] [H390-VM] wrote:
>
>
> I thought some one had some Hercules patches to allow Music IUCV to work...
>
> http://hercules390.996247.n3.nabble.com/TCP-IP-networking-via-IUCV-td48029.html
>
> Dave

Did Peter ever get that to the stage where the rest of us could play
with it?

>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: 24 February 2017 14:44
>> To: [hidden email]
>> Subject: Re: [H390-VM] Re: [hercules-os380] About Berkeley db-1.85.
>>
>>
>> > Was this IUCV?
>> >
>> > I ask only out of curiosity, since I appreciate that IUCV isn't in
>> > VM/370 (as available) or in Hercules. However it is supported to some
>> > extent by the defunct Sim390, which apparently uses it to provide
>> > networking to MUSIC/SP.
>> >
>> Implementing the B2F0 instruction is just a matter of coding it ;)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


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

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


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

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/H390-VM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/H390-VM/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

12