No need for apologies as far as I am concerned. The result was not what
you expected and you did not find the reason in the documentation. 

You had a cause, just not the one you broadcast. :-)

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: CMSTSO Pipelines Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
> Sent: Wednesday, October 29, 2008 5:52 PM
> To: [email protected]
> Subject: Re: SPECS X2D vs astonishment factor
> 
> My apologies to the list, and the Piper: -127 was my typo.
> 
> Prefixing the rdev with leading zeros is a perfect solution - 
> thank you!
> 
> I still think X2D doc would be beneficial, along with your 
> very concise example.  That completely eliminated my 
> astonishment factor.  :-)
> 
> Actually, examples of each f2t conversion along those same 
> terse lines might be useful.   Rexx doc has some almost as brief.
> 
> Mike Walter
> Hewitt Associates
> 
> 
> 
> 
> ----- Original Message -----
> From: "Schuh, Richard" [EMAIL PROTECTED]
> Sent: 10/29/2008 05:08 PM MST
> To: [email protected]
> Subject: Re: SPECS X2D vs astonishment factor
> 
> 
> 
> I got a slightly different result:
> 
> pipe literal FFFF 00FFFF | spec w1 x2d 1 w2 x2d nw | cons
>          -1       65535
> 
> I believe that -1 is the correct value if the high order bit 
> is treated as a sign. -127 is really astonishing.
> 
> You can always contrive to have at least 1 high-order 0. X2D 
> does not display the leading zeros, so it is safe to do.
> 
> I found precious little in the documentation for X2D. For 
> B2D, it is documented that the source is treated as a signed 
> (two's complement) binary number.
> 
> Regards,
> Richard Schuh
> 
> 
> 
> > -----Original Message-----
> > From: CMSTSO Pipelines Discussion List 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
> > Sent: Wednesday, October 29, 2008 3:32 PM
> > To: [email protected]
> > Subject: SPECS X2D vs astonishment factor
> >
> > The search
> > http://vm.marist.edu/htbin/wlvindex?cmspip-l#search isn't 
> turning up 
> > anything (and I mean ANYTHING!)... looks broken.
> >
> > Maybe I'm just having a bad day (probably), or maybe the doc is a 
> > little weak (maybe).
> >
> > In a stream of records with real device addresses (the 
> usual hex, from
> > 0000-FFFF) in them.  I'd like to select those within a 
> certain range.
> > The records (from a CP directory) look like (where vdev and 
> rdev are 
> > the hex address within the 0000 to FFFF range):
> >
> > _userid_ DEDICATE vdev rdev
> >
> > I was using:
> > ...
> > '| SPECS W1.3 1 PAD 0 W4 NW.4 RIGHT' , /* Ensure 4-digit hex number 
> > for
> > X2D   */
> > '| SPECS W1.4 1 W4 X2D NW' ,           /* Convert rdev to 
> decimal for
> > compare */
> > '| PICK W4 >==' loDevNum ,
> > '| PICK W4 <==' hiDevNum ,'
> > ...
> >
> > That X2D conversion works "as expected" in rexx.  E.g. FFFF =
> > 65535 But with SPECS X2D, FFFF = -127 Obviously, it's 
> respecting the 
> > high order bit.
> > High astonishment factor.  Makes me wonder what older pipes I've 
> > written using this type of conversion which will eventually fail?
> >
> > I must have missed the doc in the Piper's manual that explains this 
> > (it certainly wasn't in the SPECS doc).  To be fair, it does state:
> > "Note that the REXX name for a conversion function can be 
> > misleading:".
> > Where should I look for the doc?
> >
> > And... is there a better way to do this?
> >
> > Maybe tomorrow won't be another bad day...
> >
> > Mike (relapsing back to plumber's apprentice) Walter Hewitt 
> Associates 
> > Any opinions expressed herein are mine alone and do not necessarily 
> > represent the opinions or policies of Hewitt Associates.
> >
> >
> >
> >
> > The information contained in this e-mail and any accompanying 
> > documents may contain information that is confidential or otherwise 
> > protected from disclosure. If you are not the intended recipient of 
> > this message, or if this message has been addressed to you 
> in error, 
> > please immediately alert the sender by reply e-mail and then delete 
> > this message, including any attachments. Any dissemination, 
> > distribution or other use of the contents of this message by anyone 
> > other than the intended recipient is strictly prohibited. 
> All messages 
> > sent to and from this e-mail address may be monitored as 
> permitted by 
> > applicable law and regulations to ensure compliance with 
> our internal 
> > policies and to protect our business. E-mails are not secure and 
> > cannot be guaranteed to be error free as they can be intercepted, 
> > amended, lost or destroyed, or contain viruses. You are 
> deemed to have 
> > accepted these risks if you communicate with us by e-mail.
> >
> 
> 
> 
> 
> The information contained in this e-mail and any accompanying 
> documents may contain information that is confidential or 
> otherwise protected from disclosure. If you are not the 
> intended recipient of this message, or if this message has 
> been addressed to you in error, please immediately alert the 
> sender by reply e-mail and then delete this message, 
> including any attachments. Any dissemination, distribution or 
> other use of the contents of this message by anyone other 
> than the intended recipient is strictly prohibited. All 
> messages sent to and from this e-mail address may be 
> monitored as permitted by applicable law and regulations to 
> ensure compliance with our internal policies and to protect 
> our business. E-mails are not secure and cannot be guaranteed 
> to be error free as they can be intercepted, amended, lost or 
> destroyed, or contain viruses. You are deemed to have 
> accepted these risks if you communicate with us by e-mail. 
> 

Reply via email to