There are two help files. PIPE HELP explicitly states that 16 is the maximum 
valid value. PIPE AHELP states:

"Operation:   A 16-character timestamp is developed whenever a record has been
read.  It consists of the year (including the century), the month, day, hour,
minute, second, and hundredth of a second.  The specified number  of  charac-
ters  are  taken  from the right-hand side of this number and prefixed to the
input record."

I see no statement that anything is unspecified in either help file or the 
Author's Edition PDF.                                                           
      

I will agree that that inferring from IBM documentation is not good for our 
health or well being, but in a case like this there is an explicit statement 
that the generated length is 16, not 18. It does not state what the action will 
be if n > 16 is entered. It does not say that the result will be padded to n or 
that 16 will be assumed in place of the stated value for n. 

I agree that a message is more appropriate than unpredictable results when an 
invalid value is specified; for example, messages like the one produced when n 
< 1 is specified for a timestamp stage. However, in this case I see nothing 
that should lead you to the conclusion that a value greater than 16 would yield 
good results. 

FWIW, the old Pipelines does produce a 16 byte timestamp if n > 16 is 
specified. 

pipe literal <<<| timestamp 18 | cons 
2009072117004800<<<  

pipe literal <<<| timestamp 1000 | cons 
2009072117004800<<<                   

Unexpected, perhaps, but possibly better than garbage. On the other hand, if 
one assumes that the timestamp is 18 or 1000  bytes long, subsequent stages may 
get it all wrong and still produce garbage.  

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: CMSTSO Pipelines Discussion List 
> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Paul Gilmartin
> Sent: Tuesday, July 21, 2009 9:12 AM
> To: CMS-PIPELINES@VM.MARIST.EDU
> Subject: Re: Garbage in timestamp stage output
> 
> On Jul 21, 2009, at 10:05, Schuh, Richard wrote:
> 
> > "Valid values are 1 through 16."
> >
> Have you read what the OP said was unspecified?
> 
> >> -----Original Message-----
> >> From: CMSTSO Pipelines Discussion List 
> >> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Paul Gilmartin
> >> Sent: Tuesday, July 21, 2009 9:00 AM
> >> To: CMS-PIPELINES@VM.MARIST.EDU
> >> Subject: Re: Garbage in timestamp stage output
> >>
> >> On Jul 21, 2009, at 09:42, Schuh, Richard wrote:
> >>
> >>> The help file certainly does specify it:
> >>>
> >>>  Operands
> >>>
> >>>  n
> >>>      specifies the number of characters to include in the
> >> timestamp.
> >>> Valid
> >>>      values are 1 through 16.  The default is 8.  If n is 
> less than 
> >>> 16, the
> >>>
> >> I don't see where it's specified, either in the help file 
> itself, or 
> >> in the excerpt you provided.  It would be nice if invalid values 
> >> caused an error to be reported.  (But I'm unable to reproduce the 
> >> OP's (mis-)behavior.  Perhaps I'm at a different level.)
> >>
> >>>> -----Original Message-----
> >>>> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Bruce Hayden
> >>>> Sent: Tuesday, July 21, 2009 5:53 AM
> >>>>
> >>>> The discussion about timestamps had me look at the
> >> timestamp stage,
> >>>> and I noticed that arguments above 16 to that stage make
> >> it produce
> >>>> unexpected output:
> >>>> pipe literal|timestamp 17|cons
> >>>> 8888888888888888.
> >>>> Ready;
> >>>> pipe literal|timestamp 18|cons
> >>>> È8È8È8È8È8È8È8È8..
> >>>> Ready;
> >>>>
> >>>> The help file doesn't document that the argument must be
> >> 16 or less,
> >>>> but then again it also doesn't specify what it does with 
> arguments 
> >>>> larger than 16.  This was tested on sublevel 20.
> 
> --gil
> 

Reply via email to