× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Removing keys from Keyed Physical File
  • From: Buck Calabro <kc2hiz@xxxxxxxxx>
  • Date: Fri, 22 Feb 2019 15:21:19 -0500
  • Autocrypt: addr=kc2hiz@xxxxxxxxx; keydata= mQGiBEcbaT4RBADqmM9OgXil65pjrxclJpxuAF6vraI3kkmJbEHb5ElL7EquHE3QDuFqFgIB 4NZLHDbVAh0AD5exAX+r+xg//UvtBc2k34HROnCpWTMnIOaSVhhVjpYEbZGLz6wfrRpu4Qyn 45iaKT4F0qcHo+0LrGQPef3xrFkUhxURgzY5zgo6+wCg/XjYJ155witPWB2CbNf6RAm9QT0D /jSp6YhvE3xPE12aBuRYM678JTbaQfuYv4HUfug1Wz/0zH5btfEihWVN4wbKaoQ/H/29v2TP /Lyh8XTVd3Z0rz4iaSD5fGicn81WPANBeIepLB8vpfEik6UhHpN1DJkz6Ryw2mgx8p53LhHV Ck4Jt0HP2TAl3f7QTXGFOiFzJwEqBACsHk/gFpKAHdv7n4vJoHqp0RNgOOyhnTThlulPilt6 tAaSe10FOrrugBuLMn7wXBANQ1ApmIb5yNjhYqPREj65OVv2MUbw8H2HnQs//Z6aodyR/kzU 2q2G9A/YFI1LL0m/gvaVbEj/wE0ybBgFkrcoEFeStkqS5HzLEFGUDFXhD7QfQnVjayBDYWxh YnJvIDxrYzJoaXpAZ21haWwuY29tPoiFBBMRAgBFAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAkcbdMokGGh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEvAAoJEN7KcclH umuRfngAoNXU6AXqyTR8FRuoXKBGS4k7bPUEAJ912WKSkjpCt0axjrq6j22e5XgWzbkCDQRH G2k+EAgAnLXJ9hOqedgsIYM3LuomBBNN+7WTFSVaJ3Rqz8XVZtJvLL0bIRAvpVK9L9rYXlCR cPAm0YNK6H2DR7sQxWlxEH4mWB+jTCTALpcVq+Kpfbw5qDdn+9DVMS7tBOchtTlPSGgdKgn7 sTObra8cHtX/ddTB6OLzHeTXr4PZbUwVeQdIStdwMmozKBQvgjXWKi1GiuYbwYkCM/zJEUCs J36BIE4li9xohJ5O4iKC20YVckMJfZLbn1a2gVgn6Re8C5ezNewT0qM8ZDCUNENWAxsU/c9J UCFQ2QcMU+25b84D5yPxnEKna5U9Fz2JjRjWy5ZKZx2+WhZj0r2Tw6/kGb28AwADBgf/WBsn JSMHxyVfg+LKLHpdANwa9jdrKOt2WjJbWOiJ9l7SmqD0oi3c22FFxRXKsFfjCikLk9wbLZKH SqqnOePvMMHqNcqQTSv7+ARjxnBH4g6dhqg+zmebKpt8zV2awQzYSSm4YY6IqzkWmPNAN7BU zUtSAfL4UU2PljTnT9m443aVCTXMne5l90HQv/gdJ121owg5KuGE6LodTpoR4hn9nbdKWtfY pDNoykvR+GN5y335yF2Zp/j6QgdxWezjou5Y3/6PUZLEsJagWe9hAcKb1eiO2bmg+1bFYu0T g5Mvb27nqfFeHHFysC7a7sXtxp/pqNLNDcK6j/7Th6vF7/n98YhJBBgRAgAJBQJHG2k+AhsM AAoJEN7KcclHumuR9SgAnRuJWHon4GP58xbqCiFR/jSUfvRgAJ47KZ1UNoXgdftoePnbrZu6 W+poEw==
  • List-archive: <https://archive.midrange.com/midrange-l/>
  • List-help: <mailto:midrange-l-request@lists.midrange.com?subject=help>
  • List-id: Midrange Systems Technical Discussion <midrange-l.lists.midrange.com>
  • List-post: <mailto:midrange-l@lists.midrange.com>
  • List-subscribe: <https://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=subscribe>
  • List-unsubscribe: <https://lists.midrange.com/mailman/options/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=unsubscribe>

On 2/22/2019 2:46 PM, Robert Rogerson wrote:
Charles, then my understanding of something is incorrect (wouldn't be
the first time).

Here is a date field in one file in DSPFFD

              Data        Field  Buffer    Buffer        Field
   Field      Type       Length  Length  Position        Usage
   SBDATE     DATE           10      10         1        Both
     Field text  . . . . . . . . . . . . . . . :  Sales Date
     Date Format . . . . . . . . . . . . . . . :  *ISO
     Default value . . . . . . . . . . . . . . :
         '0001-01-01'
     Coded Character Set Identifier  . . . . . :     37

And if I look at the file in WRKMBRPDM

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7
2018-02-260030607911615300007341002632 0000004000034507122870001-01-01
2018-02-260040607911615300007341002632 0000005000034507122880001-01-01
2018-02-260100607911615300007341002632 0000003000034507122890001-01-01
2018-02-260110607911615300007341002632 0000002000034507122900001-01-01


If I do the same for the file in question...

           Data        Field  Buffer    Buffer        Field
Field      Type       Length  Length  Position        Usage
FRDAT      DATE           10      10        11        Both
  Field text  . . . . . . . . . . . . . . . :  From Date
  Date Format . . . . . . . . . . . . . . . :  *USA
  Coded Character Set Identifier  . . . . . :     37

And if I look at the file in WRKMBRPDM

*...+....1....+....2....+....3
á█|█ä█¤71011/01/201812/31/2022
á█|█ä█¤71411/01/201812/31/2022
á█|█ä█¤71511/01/201812/31/2022

Am I misunderstanding something?

We tend to think that DSPPFM is showing us the 'raw' contents of the
table, but that's not the case. DSPPFM is interpreting the date column
and formatting it nicely for us to understand. So a *YMD gets formatted
differently to a *ISO. In both cases, the underlying (raw) data is in a
form that's ugly for us humans.

With respect to the actual problem, I've learnt the hard way that if I
have an SQL table, I should only manipulate it with SQL and not with CL
commands. You might consider SET OPTION DATFMT, or the scalar function
VARCHAR_FORMAT()
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/db2/rbafzscavarcharformat.htm


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.