HP3000-L Archives

June 1998, Week 3

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:
Steve Miller <[log in to unmask]>
Reply To:
Steve Miller <[log in to unmask]>
Date:
Wed, 17 Jun 1998 08:01:00 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
This message was sent to the following destinations:
  1 HPLIST@INTERNET
   [log in to unmask]
  2 POWERH@INTERNET
   [log in to unmask]
______________________________________________________________________________
We are (finally) in the process of migrating our HP3000 Powerhouse programs
from 6.09 ro 7.29c8.  In recompiling the Quick screens, I'm getting an
interesting behaviour that I can't explain.

We often display record items in smaller screen fields than their record
definition allows (we make the definitions far big enough to handle future
growth).  Under 6.09 this was done with a PIC option on the FIELD statement.
For example, a ITEM that was 7 digits in the dictionary may have a PIC '^^^^^'
on the screen, which displayed 5 digits on the screen.

Under 7.29c8, these same screens (unchanged in any way) are taking at least one
extra position beyond the PIC per field.  In otherwords, the example above
would create a screen field of 6 character.  This often causes fields to
overwrite other fields or titles.  It is almost as though a sign byte was being
forced.

However, if I define a TEMP item exactly the same as a dictionary item, then
put a smaller PIC option on the field, it works as expected (and as 6.09 did),
taking only the space of the PIC.

I called Cognos Support, and was basically told "However it seems to be working
is how it should work".  (I guess that's what you get for the $90,000 upgrade
extortion fees!).  I was told that I should use a SIZE option to limit the
field.  BUT, the Quick Manual says under SIZE: Specifies number of characters
in the ENTRY field.  It further says: Normally this option isn't required since
the size of the field is determined from the PICTURE!

Has anyone else experienced this behaviour, or have any suggestions?  Using
the size option does seem to work as a fix, but I'd love an answer as to why
this happens, and if there are any better ways short of adding SIZE options to
dozens of fields in possibly hundreds of programs.

Steve Miller
Portion Pac, Inc
[log in to unmask]

ATOM RSS1 RSS2