On 09-Jan-2015 10:37 -0600, John McKee wrote:
<<SNIP>>
If a remote drive craps out - it is in a RAID set, is there any
potential data loss? They are keeping things in output queues because
there is no alternative.
They need to keep the content,
If there is no /backup/ of the spool files, then just some hiccup
that could be unrelated to RAID, might leave them with no recovery of
that data; obviously loss of the RAID set means a reload. So although a
full system save may exist, IIRC the save\backup of spool files is not
included; saving spool data must be done explicitly, separately. Thus
if there is a loss requiring recovery, I expect their "need" may not be
able to be met.
which brings up the related question, and I am thinking no easy
answer here. Remote is v5r3. Can the spool files be converted to PDF?
I am cringing at the thought of doing this for 171423 or even 11,736
files.
Converting the spool files into anything that can and will be saved
by a full system save, seems should be a priority. I seem to recall a
KB\TechNote document that documented some tooling to effect that.
Due to large outques (OUTQ) and I don't know how much actual junk,
if SPOOLTOOLS could do conversion to PDF (again, on v5r3 system),
could it be installed without pushing Dasd over the edge? System is
at 88.5142 of 317.1G.
Any conversion of the spool data to another form whereby storage for
the output is local to that same system would likely best effect
deletion of the since-converted spool and then\eventually reclaim the
storage for the deleted spool file(s) to avoid unnecessarily increasing
the amount of storage required. IIRC the Reclaim Spool Storage
(RCLSPLSTG) command was discussed in a prior discussion about the
capacity concerns on the remote system.
I created a user profile on local 520 (v5r4) with same user name
and password as my profile ob the remote system. Still could not open
a DDM file. Same error and reason code - 17.
I recall the setup was TCP/IP DDMF, and someone informed looking into
the use of the Add Server Authentication Entry (ADDSVRAUTE) [or Add
Server Authentication Entry (qsyaddserverentry) API] to establish
access. Other possible issues [because IIRC the unstated error\rtncde
may indicate something about authentication compatibility] might be the
Password Level (QPWDLVL) differences which would be irrespective the
/same/ uid\pwd. I do not think the Retain Server Security Data
(QRETSVRSEC) indicator plays any role, but perhaps worth a review.
Make sure the remote system is /listening/ to the ddm and ddm-ssl
well-known ports using Work With TCP/IP Network Status (WRKTCPSTS) for
connections; NETSTAT *CNN or WRKTCPSTS OPTION(*CNN)
Verify configuration of the TCP/IP DDM server and ensure the server
is started; Change DDM TCP/IP Attributes (CHGDDMTCPA) and Start TCP/IP
Server (STRTCPSVR). For the former, review the Password Required
(PWDRQD) attribute; the following should present the current config:
?CHGDDMTCPA
Maybe there is an exit program involved, but command to look at exit
programs has slipped away from active memory.
Work With Registration Information (WRKREGINF) and Display Network
Attributes (DSPNETA).
Maybe it is just file authority.
As I recall the RC17 [message identifier not stated this time] is for
an error about the connection authentication\authority, which is before
any remote file is ever accessed; i.e. the connection is not even being
established.
My login is tied to a group profile so when I sign on, I have needed
authority to access files. Maybe whatever job provides DDM service
needs that authority - if so, what profile is that?
With APPC\SNA DDM connections, there was a default user for the
communications, and that was usually QUSER; I think that is not germane
not only for use of TCP/IP, but because again, the method for the server
authentication is probably the issue.
I deeply appreciate your patience and assistance. This whole process
is rapidly approaching the looney stage.
Just my opinion, but these discussions seem never to have a single
direct and specific purpose, and when there are several specific items
to address, they never seem to be followed through to any sort of
logical conclusion, and instead per lack of feedback on any suggested
actions may leave the responders\readers with the impression that there
may have been only some dabbling rather than trying to progress the issue.
midrange.com
