HP3000-L Archives

May 1999, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Thu, 27 May 1999 13:30:55 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
X-no-Archive:yes
Rereading your message, is the main question how to avoid the 'EXTENT SIZE
EXCEEDS MAXIMUM' message? This is caused by accepting the default number of
8 extents on your BUILD. Changing DISC= to DISC=10000000,32 got past this
problem, onto the next one: INVALID RECORD SIZE SPECIFICATION  (FSERR 10).
While I couldn't find this limit in HELP FILE, -32767 seems to be the limit.
If there is a way around this, I am not familiar with it. Others have
already pointed out other interesting questions about what this process is
trying to do, and MPE limits. It would seem that moving that much data on a
regular basis might not make as much sense as finding a way to access on its
native platform.

I am not familiar with Datablaster, but will address what I can without
doing some research. I assume that acquiring TCP for the mainframe or SNA
for the 3000 or any additional products is not a preferred solution. I would
point out that doing so may pay for the product(s), by saving developer
time, and run time. That aside, here are some things to consider.

Do you know what the limiting factor, what the bottleneck is?

Does Datablaster compress the data in anyway? Depending on the speed of the
connection, compressing can be justified, especially for so much data.
Unfortunately, I do not know if LZW has been ported to the mainframe. I know
that PKZip has, but I don't think that it's free. Perhaps someone else has
already looked at the question of compression programs available for both
MPE and mainframes (although you do not way which mainframe or OS you are
using).

Also, why convert from EBCDIC? Why not just read the file as EBCDIC on the
3000? This is especially easy if you are writing in COBOL. Or, has anyone
benchmarked the result of telling FCOPY that this is EBCDIC, and letting it
do the conversion?

Finally, and perhaps most helpful, have you OCTCOMPed FCOPY? There was a
thread on this and how it improves performance earlier this year, that you
should be able to find in the list archives.

One nit-picking tip: don't purge and build. FILE equate with ,OLD;SAVE, then
PURGE *fileq:
FILE CBCONV3.CBARBAR1;RESET,OLD;SAVE
PURGE *RESET
This zeros the file, without having to specify or maintain buildparms in the
job.

ATOM RSS1 RSS2