Re: Anyone on V6R1.

I won't suggest that you store the control block information in the stream
file, just the data. All the control block information would stay in the a
standard table or at least that I how I would do it. My point is that spool
data is inherently stream in nature. Why not store it in a stream file
instead of the crazyness of creating new files and multiple members and data
between members and data between files, etc, etc. It would seem that would
solve conflict issues that exist currently. You could also store it
compressed and even encrypted if you wanted. I am referring to problems
discussed in previous post to the forum.

Since all spool I/O is through a file interface won't you be making changes
in one place? Their may be issues I don't know about.

On Thu, Sep 3, 2009 at 4:24 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Alan Campin wrote:

Bummer. I wonder why IBM holds on to that system when they
have the IFS with all of the problems they have with QSPL?

On Thu, Sep 3, 2009 at 1:12 PM, Pete Massiello

NO, they still use QSPL libraries

Not sure what problems alluded.... And is that question asking
why not use stream files instead of database file in QSPL because
all of the problems with QSPL, or why not use stream files because
those are equivalently problematic as QSPL ;-)

Unless a problem was specific to the implementation object,
changing what object [type] is used would probably be moot in most
cases.? What problem(s) would justify a rewrite from using database
to stream I/O? If the common data management allowed a transparent
redirect, then perhaps not a huge deal [i.e. effectively no change,
but an override to STMF], but otherwise difficult to justify.

FWiW One reason database members had been used is because the
spooling also supports job /spooling/ from fixed record length with
support for *SRC & *DATA inline //DATA which of course are the two
types of database physical file members. That part would probably
remain unchanged even if the implementation object changed. IIRC
there was also for some time an issue whereby stream file limits
were too small to hold the largest spool files in one object; the
original spool control block was designed to have one spool file
entry to point to the description and data of each, with just the
one pointer.

The database member implementation object also enables storing
control information beyond just the /object/ information [e.g.
owner, text, expiration, et al]. If stored in stream files, then
all accesses would have to be binary anyhow, so those details could
be stored before or after the actual spool data into the same space;
the maximum amount of spool data in a file would be limited by the
control information, but now that stream files can be so large,
hardly a concern anymore. But if the control information were just
stored in the data [instead of in the object], why not just rewrite
the OS to work like a PC ;-)

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.