Problem Solved
Hamilton, Allison
Allison.Hamilton@Cognos.COM
Fri, 21 Jul 2000 09:39:58 -0400
OpenVMS dynamically extends files as it requires space, to the limit of the
disc space available. (I believe that UNIX is the same.) MPE/iX
pre-allocates file limits and then eats up space as it requires it to that
limit, but not beyond, thus the requirement for a max expected size on
MPE/iX machines. Yes, there may be products that go in a twiddle the file
system to bypass this restriction, but the file system doesn't support it
directly. This is why OpenVMS and UNIX have NOLIMIT, and MPE/iX does not.
-----Original Message-----
From: Johnson, Tracy [mailto:Tracy.Johnson@trw.com]
Sent: Friday, July 21, 2000 9:32 AM
To: powerh-l@sphere.swau.edu
Subject: RE: Problem Solved
I use a different approach. As noted on MPE/iX systems, you must
use a fixed SET REPORT LIMIT or a fixed SET PROCESS LIMIT (oddly
enough, you can have unlimited sizes on the VAX and HP-UX version,
but I still prefer the HP3000. Of course it makes one think,
with the advent of Posix on the HP3000 do you think Cognos will
ever add the NOLIMIT option to their MPE/iX version?)
I digress...
Rather than make the largest size the system can hold, I take a
logical look at the dataset in question and say to myself:
"Will my Quiz or QTP run create a subfile or report that is larger
than the largest dataset I'm reading?" In MOST cases the answer is
"No." Sometimes it will, as in those cases when you're linking
files with the OPTIONAL clause, then it is possible to have
a report or process size that is a multiple of the linked file
sizes. But I won't attempt to address that here.
So, I've created the following VERY SIMPLE command file in MPEX,
that is run against the largest file that I'm using. For
Turbo/Image files you must use the true MPE name
(i.e.: FINDB01.GROUP.ACCOUNT):
USER DEFINED COMMAND FILE: REPLIMIT.COMMAND.SYS
PARM FNAME
IF FINFO("!FNAME",-9) = -401 THEN
RUN MAIN.PUB.VESOFT,MPEX;INFO="SETVAR REP_LIMIT
VEFINFO('!FNAME').DBSETENTRIES"
ELSE
RUN MAIN.PUB.VESOFT,MPEX;INFO="SETVAR REP_LIMIT VEFINFO('!FNAME').EOF"
ENDIF
ECHO SET REPORT LIMIT !REP_LIMIT > REPLIMIT
RUN MAIN.PUB.VESOFT,MPEX;INFO="ALTFILE REPLIMIT;FLIMIT=EOF"
What it does, is create a USE file in the Temporary file
domain that you can use in Quiz. Logically, it won't be
larger than your largest dataset. In your job file it will
appear as follows:
!XEQ REPLIMIT FINDB01.GROUP.ACCOUNT
!QUIZ
>USE REPLIMIT
>... more quiz statements.
(By default, the MPE temporary file of REPLIMIT will have 1000
records, the last line in the command file brings it back down
to 1 record.)
For QTP, I have a similar file:
USER DEFINED COMMAND FILE: PROLIMIT.COMMAND.SYS
PARM FNAME
IF FINFO("!FNAME",-9) = -401 THEN
RUN MAIN.PUB.VESOFT,MPEX;INFO="SETVAR PRO_LIMIT
VEFINFO('!FNAME').DBSETENTRIES"
ELSE
RUN MAIN.PUB.VESOFT,MPEX;INFO="SETVAR PRO_LIMIT VEFINFO('!FNAME').EOF"
ENDIF
ECHO SET PROCESS LIMIT !PRO_LIMIT > PROLIMIT
RUN MAIN.PUB.VESOFT,MPEX;INFO="ALTFILE PROLIMIT;FLIMIT=EOF"
The job file looks like this:
!XEQ PROLIMIT FINDB01.GROUP.ACCOUNT
!QTP
>USE PROLIMIT
>... more QTP statements.
Tracy M. Johnson
TRW Automotive Electronics
Sensors & Components
> -----Original Message-----
> From: Glenn Waters [mailto:Glenn_Waters@ncsu.edu]
> Sent: Friday, July 21, 2000 7:32 AM
> To: powerh-l@sphere.swau.edu
> Subject: RE: Problem Solved
>
>
> Back in my MPE days we did something similiar to what you are
> saying, but with a little twist. Anyone using HP's should be
> familiar with MPEX. We used the MPEX functions to expand the
> file to something large, run the programs that wrote to it,
> then used MPEX to compress the file back down. It's been a
> while since I was on a 3000 so I can't remember the actual
> commands, but that functionality has been with MPEX since the
> "early" days.
>
> Glenn
>
> At 01:19 PM 7/21/2000 +0200, you wrote:
> >Why not simply open the largest file the operating system
> will allow (currently 4GB on MPE/iX 6.0)? So calculate the
> number of records as 4GB / Recsize, and "open" the output
> file as that.
> >
> >MPE only allocates sectors as it needs them, I think, so a
> big file that can hold 4 million 1024Byte records but ends up
> with 1 record in it takes 256 sectors (see below).
> >
> >Or am I off the track here?
> >
> >Neil
> >
> >
> >/:l bigfile,2
> >
> >ACCOUNT= NHA GROUP= DEV
> >
> >FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> >
> >SIZE TYP EOF LIMIT R/B SECTORS #X MX
> >
> >BIGFILE 1024B FA 1 4000000 1 256 1 32
> >
> >
> >
> >
> >-----Original Message-----
> >From: Deskin, Bob [mailto:Bob.Deskin@Cognos.COM]
> >Sent: 21 July 2000 10:24
> >To: powerh-l@sphere.swau.edu
> >Subject: RE: Problem Solved
> >
> >I would be amazed if we hadn't encountered this one in the
> deep dark distant past. Now that the problem has been solved
> (thanks Mike), I realize what's happening. We use the REPORT
> LIMIT for all sorts of disk file limits because MPE/iX
> doesn't have dynamic disk allocation. When you create the
> file you need a size. So what do we use on the report file to
> disc? The REPORT LIMIT of course. Not counting on there being
> any headings and footings in the report (du-uh) :-(
> >
> >I don't know if there's anything we can do physically in
> QUIZ to resolve this. Logically, you'd think that we could
> count the expected lines, but we don't know how many control
> breaks there will be.
> >
> >However, I do agree that the report should not output what
> it does. Please file this as a bug. We should abort the
> report if the output disk file overflows. If you can get the
> bug number, please send it to me and I'll see what I can do.
> This really is a report integrity problem. Imagine if you
> were printing checks/cheques.
> >Bob Deskin
> >PowerHouse Web Product Manager and Senior Product Advisor
> >Application Development Tools, Cognos Inc.
> >bob.deskin@cognos.com
> >(613) 738-1338 ext 4205 FAX: (613) 228-3149
> >3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA
> >-----Original Message-----
> >From: Ron Burnett [mailto:ron@cryptic.rch.unimelb.edu.au]
> >Sent: July 20, 2000 8:38 PM
> >To: powerh-l@sphere.swau.edu
> >Cc: juristam@cryptic.rch.unimelb.edu.au;
> anna@cryptic.rch.unimelb.edu.au
> >Subject: Problem Solved
> >
> >At 18:07 20/07/2000 -0400, Mike Godsey wrote:
> >>I have had this happen before. Increase the process/report
> limit. What
> >>happens is it creates a fixed size file that completely
> fills and then PH
> >>resets the file and continues to write records beginning
> again at the start
> >>of the file.
> >
> >This was the perfect solution ...... the output file was
> being closed on
> >reaching its limit, and then reset and re-opened leaving me
> with only
> >the tail end of what I expected.
> >
> >It would be nice if there were more intelligent clues printed in the
> >STDLIST. Does anyone else see this as a bug (or at the very least,
> >an unfriendly feature)? QUIZ should abort on reaching an
> output file
> >limit. Its not much use getting an output file that doesn't
> contain what
> >your program asks for.
> >
> >Many thanks to all who replied to my message.
> >
> >Ron Burnett
> >Women's & Children's Health
> >Melbourne, Australia
> >ron@lis.rch.unimelb.edu.au
> >
> >= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = = = = = Subscribe: "subscribe powerh-l" in message
> body to majordomo@lists.swau.edu Unsubscribe: "unsubscribe
> powerh-l" in message to majordomo@lists.swau.edu This list is
> closed, thus to post to the list, you must be a subscriber.
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = = = =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> This list is closed, thus to post to the list, you must be a
> subscriber.
>
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.