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



I'm thinking that once I specified ELAN as the line, I no longer need QESLINE, and maybe it is trying it at the end and failing that part? But it did appear to get out, and the verify function was successful.

I will certainly investigate the resource and see if it offers a better description than I found so far.

Thanks Kendall.

Kendall Kinnear <Kendall.Kinnear@xxxxxxxxxxx> 12/18/2014 3:54 PM >>>
There are detailed instructions for setting up Service Agent at http://www-01.ibm.com/support/docview.wss?uid=nas8N1018592. Once that setup is done, SNDPTFORD should work fine.

It is not as simple as changing QESLINE and the setup is dependent on the release you are running.

There are software prerequisites, ports that have to be open on the firewall, etc.

Respectfully,
Kendall Kinnear
System Analyst
Standard Motor Products, Inc.
Work: 972-316-8169
Mobile: 940-293-7541

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buddy McClean
Sent: Thursday, December 18, 2014 3:42 PM
To: Midrange Systems Technical Discussion
Subject: Re: Another PTF Question

Looks like SNDPTFORD is the choice. Brush away the cobwebs on my skills ( such as they were ) for changing QESLINE from it's current *SDLC to use ethernet.
Hopefully it doesn't take a dedicated ethernet line.

Charles Wilt <charles.wilt@xxxxxxxxx> 12/18/2014 3:23 PM >>>
You shouldn't need (the parts of?) Systems Director you'd need to pay for to get SNDPTFORD...



On Thu, Dec 18, 2014 at 3:27 PM, Buddy McClean <Buddy.McClean@xxxxxxxxxxxx>
wrote:

Oh well guess I'm going to have to modernize out of the 90's,
SNDPTFORD has never been set up and it looks like SYSTEMS DIRECTOR is
a for-charge software product.


Thanks Chuck, beginning to make sense.

The only way to use the *SERVICE option of the load ( which they say I
have to use ) is to use the SNDPTFORD system or SYSTEMS DIRECTOR to
take the downloaded .SAVF , register it, then put it up for apply.

I have never used SNDPTFORD and don't know if it even works, but this
might be the day.

CRPence <CRPbottle@xxxxxxxxx> 12/18/2014 12:12 PM >>>
On 18-Dec-2014 10:37 -0600, Buddy McClean wrote:
<<SNIP>>

The documentation says that the PTFs need to be loaded from *SERVICE.
It also says that they can be download from fix central and loaded
via *SAVF. The option on loading a PTF has either *SERVICE or *SAVF.

The Device (DEV) parameter of the Load PTF (LODPTF) does support
both special values. When *SAVF is specified, that is a request to
redirect to the information provided on the Save File (SAVF)
parameter. When the value *SERVICE is specified, the implication is
that the /Load/ request is to obtain the PTF images whence they were
placed by the "service support system"; as I recall, these were always
individual PTF save files [named Qptf_id in QGPL], but possibly they
could be stored elsewhere.?

When they say *SERVICE in the documentation, do they also mean *SAVF
if you downloaded it manually and is it a matter of just creating a
SAVF and using FTP to get the .BIN moved to the Iseries.

A *FILE object with the SAVF attribute may have any various
content; e.g. a binary image as the effect of an operation such as
SAV, SAVOBJ, etc. If that content of the Save File just happens to be
a binary PTF image, that would not necessarily be known to the PTF
[PZ] feature of the OS; a PTF image that is _in_ *SERVICE is a PTF
[that is in a Save File] that previously has been /registered/ with
the PTF feature of the OS. For example, if I issue the Create Save
File (CRTSAVF) command and then copy the binary records of the
save-file from another Save File with PTF content into my new\empty
save file that I had just created, e.g. copied via FTP PUT, then that
new Save File is unknown to the PTF feature; the new save file was
never /registered/ with the PTF feature of the OS.

Basically does *SAVF imply *SERVICE, just from a different source (
manual vs automatic download ).

Somewhat; only *if* the SAVF was created by a download feature
which implicitly /registered/ the PTF image [that happens to be stored
in the Save File] with the PTF [PZ] feature of the OS. AFaIK the
manual vs automatic is not germane; the /download/, however performed,
must have registered the PTF image [irrespective of whether that is
stored in a Save File or elsewhere; i.e. I am unsure if a PTF might
reside in *SERVICE, but in a form other than a SAVF image] with the
PTF feature of the OS. I recall that the Send PTF Order (SNDPTFORD)
would, for a specific set of PTFs [optionally with requisites
requested to be included] would create save files into which the PTF
images were deposited, and those PTF Save Files would be implicitly
registered with *SERVICE.

When I download the individual PTF, I get a .BIN file, the same as
when I download more than one. There are several PTFs that need to
be applied this way, can they all be combined into one download and
one .bin file to copy to one SAVF?

A PTF save file is, AFaIK still just _one_ PTF. I do not believe
the .BIN format is compatible with the SAVF format; i.e. I do not
expect the binary data records of a .BIN can be copied into a SAVF.
As I recall, the .BIN format is used for image catalogs.

Or is it risky to apply a PTF if it was not really required, so
individual PTF downloads would be the way to go <<SNIP>>

I am not sure I understand the question. If a PTF is available for
download and applicable to the installed product\release, then the PTF
should be available for loading and applying without much concern.?

--
Regards, Chuck
--
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.

________________________________

Please consider the environment before printing this email.

The content of this e-mail (including any attached files) is confidential and may be privileged and protected by law. It is intended solely for the purpose of the person to whom it is addressed. If you are not the intended recipient of this message, please notify the sender immediately and delete the message (inclusive of any attached files). In addition, if you are not the intended recipient of this message, any disclosure, copying, distribution or taking any action in reliance of the contents of this email is strictly prohibited.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.