Re: remote 520 questions (more)

Have you looked at mail. It has a tool to convert to PDFs. If you have the appropriate license code, his software will convert spool files of most sizes to PDFs.

You could then use to save the PDFs files on a pic system.

You could then build a cross reference table on the as/400 to store then details of the spool file like owner, spool file name, outq etc. you and your users could then browse this file and retrieve spoolfiles off the remote system as required. I did this a long time back. I do not know where that code is to share. Re displaying the data would be done on a pic in the normal PDFs format.

Sent from my iPad

On Jan 9, 2015, at 3:06 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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.

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