strange behavior of f$search

[BillPedersen]

I have been working on a project and using f$search extensively in a command procedure.

The procedure has various loops and nested if statements...

The strange thing about the behavior is that the first time this particular instance of f$search is invoked it always returns a null string, as if it did not find the file even though we know the file is there and we know the symbol for the file has the correct text describing the file's location and name. There are no wildcards in this particular invocation.

All the instances use different values for the stream-id; currently 1 through 7.

This instance of f$search is in a sub-loop of the command procedure and if called several times and fails each time the first time through the main loop.

In second time through the main loop, and subsequent passes, the f$search calls that had previously failed succeed and it works as expected.

The environment is VMS Alpha 8.4 with most recent patches applied running on a Charon PersonalAlpha.

Any suggestions?

Anyone seen anything like this before?

Thanks,
Bill.

[Hans Vlems]

Did you pass a value for the stream id?
At least that's what I think it's called.

[abrsvc]

Are you sure that the filename string is completely "translated"? Are there symbols or logical names that are not getting completely translated during the first pass?

Dan

[Stephen Hoffman]

On 2015-07-17 16:48:53 +0000, BillPedersen said:

> I have been working on a project and using f$search extensively in a
> command procedure.

> ...
> The strange thing about the behavior is that the first time this
> particular instance of f$search is invoked it always returns a null
> string, as if it did not find the file even though we know the file is
> there and we know the symbol for the file has the correct text
> describing the file's location and name. There are no wildcards in
> this particular invocation.

> ...

> Anyone seen anything like this before?

The last request from f$search is supposed to be a null string, which
implies either there's some dangling context, or the spec had no
matches.

If the strings match a previous search, it's possible for the previous
search to pick up where it left off, and — if the last operation was
the last valid match — you get a null string.

Try making a bogus f$search call with the stream specified and a string
that will match nothing (to force f$search to return a null, and to
clear any previous context) before starting the "real" processing.


--
Pure Personal Opinion | HoffmanLabs LLC

[VAXman-]

In article <95ded7b0-533d-4206...@googlegroups.com>, BillPedersen <pede...@ccsscorp.com> writes:
>I have been working on a project and using f$search extensively in a comman=

>d procedure.
>
>The procedure has various loops and nested if statements...
>

>The strange thing about the behavior is that the first time this particular=
> instance of f$search is invoked it always returns a null string, as if it =
>did not find the file even though we know the file is there and we know the=
> symbol for the file has the correct text describing the file's location an=

>d name. There are no wildcards in this particular invocation.
>

>All the instances use different values for the stream-id; currently 1 throu=
>gh 7.=20
>
>This instance of f$search is in a sub-loop of the command procedure and if =
>called several times and fails each time the first time through the main lo=
>op.
>
>In second time through the main loop, and subsequent passes, the f$search c=

>alls that had previously failed succeed and it works as expected.
>

>The environment is VMS Alpha 8.4 with most recent patches applied running o=

>n a Charon PersonalAlpha.
>
>Any suggestions?
>
>Anyone seen anything like this before?
>
>Thanks,
>Bill.

I know of this DCL Debugger that might help you because *it* can view the
context symbols established by the F$search and others of its ilk.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[BillPedersen]

On Friday, July 17, 2015 at 1:27:32 PM UTC-4, Hans Vlems wrote:
> Did you pass a value for the stream id?
> At least that's what I think it's called.

No, it is being passed as a literal.

[BillPedersen]

On Friday, July 17, 2015 at 2:01:21 PM UTC-4, abrsvc wrote:
> Are you sure that the filename string is completely "translated"? Are there symbols or logical names that are not getting completely translated during the first pass?
>
> Dan

There is a logical name as part of the string. It is created at the start of the command procedure. Other calls to f$search have used logical names without issue.

The fact that the same call with the same symbol but with different contents fails the same way on all the calls on the first pass and then succeeds on the second and subsequent passes is what is difficult to accept.

So as far as I can tell it is correct, given present information.

Bill.

[BillPedersen]

On Friday, July 17, 2015 at 2:28:37 PM UTC-4, Stephen Hoffman wrote:
> On 2015-07-17 16:48:53 +0000, BillPedersen said:
>
> > I have been working on a project and using f$search extensively in a
> > command procedure.
> > ...
> > The strange thing about the behavior is that the first time this
> > particular instance of f$search is invoked it always returns a null
> > string, as if it did not find the file even though we know the file is
> > there and we know the symbol for the file has the correct text
> > describing the file's location and name. There are no wildcards in
> > this particular invocation.
> > ...
> > Anyone seen anything like this before?
>
> The last request from f$search is supposed to be a null string, which
> implies either there's some dangling context, or the spec had no
> matches.
>
> If the strings match a previous search, it's possible for the previous

> search to pick up where it left off, and -- if the last operation was
> the last valid match -- you get a null string.

>
> Try making a bogus f$search call with the stream specified and a string
> that will match nothing (to force f$search to return a null, and to
> clear any previous context) before starting the "real" processing.
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

I had tried two calls of of the same information to try that first. Nothing different.

I will try some of your suggestions to whack it about.

Bill.

[BillPedersen]

Yes, will send you a note.

Bill.

[BillPedersen]

Solved...

Like many, I ended up having blinders on for a while. But the discussions here helped me step back and execute a couple tests I had thought about but not yet followed.

Found the error elsewhere in the DCL.

Thanks, all!

Bill.

[Hans Vlems]

As my Japanese boss used to remind me: IT is part of shit :-)
Hans

[Paul Sture]

On 2015-07-18, Hans Vlems <hvl...@freenet.de> wrote:

> As my Japanese boss used to remind me: IT is part of shit :-)

When I started working with computers it was known as Data Processing,
DP for short.

Can anyone remember when "DP" was replaced by "IT"?

--
"The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led them
into it in the first place." - Douglas Adams

[Simon Clubley]

On 2015-07-18, Paul Sture <nos...@sture.ch> wrote:
>
> When I started working with computers it was known as Data Processing,
> DP for short.
>
> Can anyone remember when "DP" was replaced by "IT"?
>

For me, my perception is during the late 80s/early 90s.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Paul Sture]

On 2015-07-18, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2015-07-18, Paul Sture <nos...@sture.ch> wrote:
>>
>> When I started working with computers it was known as Data Processing,
>> DP for short.
>>
>> Can anyone remember when "DP" was replaced by "IT"?
>>
>
> For me, my perception is during the late 80s/early 90s.
>

That sounds about right and fits in with this quote (and your sig):

"I've noticed lately that the paranoid fear of computers becoming
intelligent and taking over the world has almost entirely disappeared
from the common culture. Near as I can tell, this coincides with
the release of MS-DOS." — Larry DeLuca

FWIW I met a graphics designer in the early 90s who had been
a partner in a PC dealership during the 80s. He reckoned that
early versions of DOS were so buggy that the only sane way to
use it was through dBase. Presumably the dBase folks had found
most of the bugs and devised workarounds to shield the user
from them.

--
1972 - IBM begins development on its last tape drive (3480) ever because
of the declining cost of disk drives.

[VAXman-]

In article <apdp7c-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>On 2015-07-18, Hans Vlems <hvl...@freenet.de> wrote:
>
>> As my Japanese boss used to remind me: IT is part of shit :-)
>
>When I started working with computers it was known as Data Processing,
>DP for short.
>
>Can anyone remember when "DP" was replaced by "IT"?

Yes, when it all went to shit! Circa WEENDOZE release.

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <apdp7c-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>> On 2015-07-18, Hans Vlems <hvl...@freenet.de> wrote:
>>
>>> As my Japanese boss used to remind me: IT is part of shit :-)
>> When I started working with computers it was known as Data Processing,
>> DP for short.
>>
>> Can anyone remember when "DP" was replaced by "IT"?
>
> Yes, when it all went to shit! Circa WEENDOZE release.
>

Microsoft seems to have this thing about renaming just about everything,
most likely to insure uniform confusion everywhere. Without that
confusion people might see that Microsoft shit is just that, shit.

[johnwa...@yahoo.co.uk]

I don't know when IT replaced DP but my recollection is that
Information *Services* was used in some organisations for some
period of time in between.

Then the IT Department stopped focusing on providing a service
to the organisation, and became a semi-independent (semi-parasitic?)
entity that needed to justify its existence and its budget. The
Emperor of IT started measuring his status by the size of his empire
(bigger is better) and by the performance of his team (more new
shiny things = better performing team, inevitably), rather than
considering his empire's influence on the organisation's overall
performance. (Not quite Douglas Adams, but compatible).

Once upon a time the typical IT crowd used to do some checks on
customer satisfaction, e.g. after closing a ticket, or every
couple of years across the whole userbase. The IT crowd I'm most
familiar with in recent years stopped doing the surveys, round
about the same time as the IT crowd started to look a bit rubbish
in the survey results.

There's sometimes a similar effect with broader "employee
engagement" surveys - if the results aren't what HQ want, the
survey method must be wrong, and a better approach is required.

Some organisations manage better than that.

[Simon Clubley]

On 2015-07-18, Paul Sture <nos...@sture.ch> wrote:
>
> FWIW I met a graphics designer in the early 90s who had been
> a partner in a PC dealership during the 80s. He reckoned that
> early versions of DOS were so buggy that the only sane way to
> use it was through dBase. Presumably the dBase folks had found
> most of the bugs and devised workarounds to shield the user
> from them.
>

Things had stabilised by MS-DOS 3.3, then we had the disaster that was
DOS 4.x, before the massively improved (for the time) DOS 5.0.

I can't remember if it was in the earlier versions, but DOS 5.0 came with
a simple BASIC interpreter (anyone remember gorillas.bas :-) ?).

Thinking about it a bit more, I've just realised that once again it's
another example of something which came with a whole batch of terminology
which has been left forgotten in the past.

For example, how many people today would know what a TSR was ?

[mcle...@gmail.com]

Bill,

Can you give us a few more details about the error? It might help someone else avoid falling in the same hole in future.

cheers

John

[BillPedersen]

I am working on a file synchronization application. I create some files for tracking status of the content of the directory tree. Well, I had expected the files to be there and when I checked at the end of the run, they were. Only issue was they were not there when I was checking early in the run and it should have been.

I overlooked the timestamps on the files initially.

File, yes. Correct timestamp, no.

Once I corrected the very minor error which had not created the tracking files early on then F$SEARCH behaved as expected by me in the context of the application. F$SEARCH was behaving properly all the time.

In looking at it this is the exact sort of thing you would solve quickly while using a debugger as you would be single stepping through the code and when the routine returned the unexpected result you would have gone and looked for the file right then and there; rather than chase one's tail for several hours.

Blinders for sure...

Bill.

[Rich Alderson]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> I can't remember if it was in the earlier versions, but DOS 5.0 came with
> a simple BASIC interpreter (anyone remember gorillas.bas :-) ?).

Ooh! Ooh! I know this!

MS-DOS 5.0 introduced QBASIC. Prior to that, MS-DOS 3.20 introduced GW-BASIC
(which was identical in functionality to BASICA--Advanced BASIC--on the IBM PC
family without requiring the BASIC routines in ROM as BASICA did).

We're installing a GW-BASIC exhibit at the museum, and I did the final editing/
curation for the texts.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...