× 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.



For one who doesn't use this, you sure have a lot of interest in it! ;)

You didn't say that fields had been repurposed, but you certainly implied it
by your "they've done it before" association.

Having said that, yes, it would be terrible. I have been at many
installations where home-grown tools were developed using DSPOBJD output
files and those like it. Some of them I know for sure are using dates and
times - such as one I cannot name due to NDA that compares source change
dates/times (DSPFD output) against object create dates/times. The folks
involved here are not in the business of utilities; they've used/developed
some to keep their operation running reliably and they're not funded for
such nonsense. Could they do it more efficiently? Of course. But it's
just not worth it to them.

There are many I know of like that, so probably many more that neither of us
knows about.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Nuclear war can ruin your whole compile."
-- Karl Lehenbauer


Maybe they've not modified the usage of a field. And it's not as if I
said they have. What I said was they've modified the file layouts,
which
you agree they have. Would it be so terrible if they did modify a
field
format? For example, would it have been worse to modify the format of
the
object size field instead of the stupid "if the size field is all nines
then take some other field and multiply by yet another field to
calculate
object size"?


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Dennis Lovelady" <iseries@xxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 06/24/2010 04:17 PM
Subject: RE: Problem solved, Re: Sorting DSPOBJD outfile by
ascending date
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Well, it's a pretty important allegation that IBM have historically
changed
some (any) record format. Especially in the way you are describing
(repurposing or reformatting a field). They have, many times, added to
the
record layouts (QADSPOBJ - the output format for DSPOBJD has been
through
many changes), but the kind of change you are describing is vastly
different
from that. And if you actually read those MTU I think you'll find that
to
be the case.

As far as I know, IBM have maintained compatibility for all output
files
all
the way back to V1 (and indeed to the S/38). So, I say again: what
files
were changed and when?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"What the country needs are a few labor-making inventions."
-- Arnold Glasow



I think it's a standard line in most Memo To Users about which output
file
formats got changed with a release.

Since I am constantly staying on the latest releases, and have
multiple
partitions to support, not all partitions are immediately on the new
release. (Gotta sleep sometime.) Therefore the utilities that I use
which span releases cannot be dependent on formats in output files.
API's
are my approach.


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Dennis Lovelady" <iseries@xxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 06/24/2010 02:16 PM
Subject: RE: Problem solved, Re: Sorting DSPOBJD outfile by
ascending date
Sent by: midrange-l-bounces@xxxxxxxxxxxx



This is interesting, Rob! What and when?

Has IBM changed output file
formats in the past? Yes.

If we were all using APIs instead of DSPOBJD (as you say the vendors
who
do
it right are doing), this would be a non-issue, so why do we care?
Personally, I stopped using DSPOBJD except for Q&D CL back in V2R3.
I
thought everyone had.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
Tried to play my shoehorn... all I got was footnotes!


Personally I don't care WHY it works that way. Wish it were
different.
True date field would be best. Second best would be YYYYMMDD.
Disruptive? Yes. If they changed it would customers have to
change
code?
Yes. Do I care? No. Would vendors care? Not those that do
things
right and use list api's instead of outfiles. Has IBM changed
output
file
formats in the past? Yes.

Have you submitted a DCR? Has anyone else? Have I (on this)? No.


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-
l@xxxxxxxxxxxx>
Date: 06/24/2010 12:33 PM
Subject: Re: Problem solved, Re: Sorting DSPOBJD outfile by
ascending date
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Hi, James:

Ouch! I even tried CHGSYSVAL QDATFMT 'YMD' and then ran my DSPOBJD,
but
to no avail...

I thought that someone would have entered a PMR or DCR about this
by
now
... And what about all the folks in countries where MDY is not the
popular choice for date format? This seems to have been a very
strange
choice by IBM.

Does anyone know why this works this way?

Thanks,

Mark

> On 6/24/2010 11:35 AM, James H. H. Lampert wrote:
Mark S. Waterbury wrote:

Just issue:
CHGJOB JOB(*) DATFMT(*YMD)

Then run your DSPOBJD command.

That was the very first thing I tried. Only the "Display Date" is
in
job
date format.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.