VMS features in PH

[Walker, Chris]

Views from another VMS user:

1. PHD/POW: as I've said before, I would be very sorry to lose this.

2. Mailboxes: I'd like to keep these.  I don't use them extensively, but
where I do it's usually in a situation where it would be hard to find and
alternative.  Worse, they tend to be used as part of our Powerhouse
"infrastructure", so the few instances of mailboxes are distributed through
all our applications.

3. Commandstatus/severity: I don't think I've ever used these.  If I wanted
the information I could probably get it from the corresponding CLI symbols.

4. Office: I don't use this.

5. Logicals/symbols: as long as there is some symbolic data-passing method
*that works in both directions*, I wouldn't have any problems.

6. Reverse: for the first ten years I thought this function had been
included because somebody read a beginners' C programming book.  Then I
found a use for it in a tricky formatting operation in Quiz, but of course I
couldn't use it in Quiz.

7. Set job: I wouldn't miss this because I've hardly ever used it.  I use
DCL procedures to create batch jobs because the environmental requirements
for a batch job are usually too complicated to set up with "set job".

8. Timestamp: we use Rdb, so our timestamps are Rdb ANSI timestamps, but I
can't say we use those extensively.

Chris Walker

> -----Original Message-----
> From:	Deskin, Bob [SMTP:Bob.Deskin@Cognos.COM]
> Sent:	Wednesday, March 17, 1999 1:22 PM
> To:	powerh-l@lists.swau.edu
> Subject:	RE: VMS features in PH
> 
> 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.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.