VMS features in PH

[Deskin, Bob]

Thanks for this Chris. We are indeed looking at this area and this sort of
feedback is very valuable. If anyone else has this sort of input and don't
want the entire list to get it, they can send it to me or Becky Smith, the
Product Manager (becky.smith@cognos.com).

A few comments. The Handbook is as of the 7.xx series and doesn't include
the 8.xx features or common areas.

The CACHE limit is the same on all platforms and is based on the limit built
into QUICK for OCCURS. Unfortunately this was done way back at the beginning
and changing it now would be very de-stabilizing. So don't count on any
changes in that area.

Re BACKWARDS, this is file system specific. The OpenVMS version is built on
6.2 for compatibility reasons. We'll have to look at backwards read support.

Thanks again for the input.

Bob Deskin              
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: Chris Sharman [mailto:Chris.Sharman@ccagroup.co.uk]
Sent: Wednesday, March 17, 1999 8:11 AM
To: powerh-l@lists.swau.edu
Cc: Chris.Sharman@ccagroup.co.uk
Subject: VMS features in PH


Since it would appear the future of the VMS-specific Powerhouse enhancements
is
under discussion, it would seem a good time for a review of what they are,
and
for a straw poll of their value. I've had a look through the handbook to see
what the specifics are.

Apologies to non-VMS people for filling your mailbox with mainly
irrelevance,
although you may have views on timestamps at least (see end).

First the good news:
CHAR and VARCHAR items may be up to 32K on other platforms, rather than the
paltry 2K available to us on VMS at present.
I don't know what the FILE OCCURS & CACHE limits are on other platforms (a
miserable 255 on VMS - it can only be better elsewhere).
There's a BACKWARDS file retrieval option on other platforms: RMS has
supported
this (rms$v_reverse I think) since about VMS 7.0, but PH hasn't given us
access.
Going to common code would presumably give us these enhancements.

The bad news:
1) The PHD dictionary maint feature. Lots of correspondence already here.
2) Mailboxes are no longer supported. These are obviously closely akin to
pipes.
3) Commandstatus/severity functions.
4) Office functions (All-in-1).
5) Systemvalue functionality: VMS has logicals & symbols. Other platforms
don't
	appear to offer a choice of systemvalue type (or table).
6) Reverse only exists in Quick.
7) Set job & various print qualifiers to set report.
8) Timestamp datatype & functions.

If I've missed anything please post it.

My views:
Reliability: we should probably expect to suffer slightly in the short term,
but longer term we'll hopefully get more development resource & more bugs
fixed.

1) I want PHD.
2) I occasionally use mailboxes for output, & can probably workaround this.
   	I don't see how to replace input mailbox functionality in PH, but we
	don't use it here.
3) Commandstatus/severity. Don't use this. The builtin commandok could
probably
	cover most use of this (provided it tests for odd, not zero,
contrary
	to the documentation).
4) Office. Don't use this at all.
5) Job logicals would probably cover most needs, but this change would be a
lot
	of work: we make extensive use of systemvalues to parameterise
reports,
	and to display to users which actual file they're using, when it's
	controlled by logical names.
6) Reverse. We use this a bit in Quiz for string manipulation. If the goal
is
	homogenisation, it would seem reasonable to put it in Quiz & QTP
	as well as Quick.
7) Set job etc. Don't use this at all.
8) Timestamps. Use this lots, but I don't like it now. This seems like an
	opportunity for Cognos to do it better:

I'd like a timestamp datatype which I can enter, display, find, choose by in
full (ie time fields as well as date fields). This needs format extending,
and
some sort of dateconvert (cf nconvert) to allow a date range to include
hours &
minutes etc, rather than decimals. For find to be useful, generic needs
extending from character fields to date fields too (or all fields): when you
find a record you typically don't know the exact centisecond of the
timestamp.

I don't care about delta times, so IBASEDATE is effectively the same as
VMSdate
(although the limits in the docs are wrong I think, the 64 bit format
provides
for +/-30k years).

I'd like a timestamp function which returns a datatype date, so I can do
comparisons & get the right answer (see the last section of 710G release
notes).

It would be nice to have a formatdate function like the new formatnumber, so
that I can convert dates to ascii nicely for use other than in fields.

Regards,
Chris Sharman
______________________________________________________________________
Chris Sharman			Chris.Sharman@CCAgroup.co.uk
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
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
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.